| Message ID | 20180925001832.18322-5-keescook@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | LSM: Explict LSM ordering | expand |
On Mon, 24 Sep 2018 17:18:07 -0700 Kees Cook <keescook@chromium.org> wrote: > This partially reverts commit 58eacfffc417 ("init, tracing: instrument > security and console initcall trace events") since security init calls > are about to no longer resemble regular init calls. I'm not against the change, but how much are they going to "no longer resemble regular init calls"? -- Steve > > Cc: James Morris <jmorris@namei.org> > Cc: "Serge E. Hallyn" <serge@hallyn.com> > Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca> > Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> > Cc: linux-security-module@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > security/security.c | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/security/security.c b/security/security.c > index 892fe6b691cf..41a5da2c7faf 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -30,8 +30,6 @@ > #include <linux/string.h> > #include <net/flow.h> > > -#include <trace/events/initcall.h> > - > #define MAX_LSM_EVM_XATTR 2 > > /* Maximum number of letters for an LSM name string */ > @@ -47,17 +45,13 @@ static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] = > > static void __init do_security_initcalls(void) > { > - int ret; > initcall_t call; > initcall_entry_t *ce; > > ce = __start_lsm_info; > - trace_initcall_level("security"); > while (ce < __end_lsm_info) { > call = initcall_from_entry(ce); > - trace_initcall_start(call); > - ret = call(); > - trace_initcall_finish(call, ret); > + call(); > ce++; > } > }
On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt <rostedt@goodmis.org> wrote: > On Mon, 24 Sep 2018 17:18:07 -0700 > Kees Cook <keescook@chromium.org> wrote: > >> This partially reverts commit 58eacfffc417 ("init, tracing: instrument >> security and console initcall trace events") since security init calls >> are about to no longer resemble regular init calls. > > I'm not against the change, but how much are they going to "no longer > resemble regular init calls"? My take on "regular" init calls is that they're always run, link-time ordered, etc. The changes proposed here will make it so not all initialization are run depending on runtime configurations, ordering will be flexible, etc. -Kees
On Wed, 26 Sep 2018 11:35:21 -0700 Kees Cook <keescook@chromium.org> wrote: > On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt <rostedt@goodmis.org> wrote: > > On Mon, 24 Sep 2018 17:18:07 -0700 > > Kees Cook <keescook@chromium.org> wrote: > > > >> This partially reverts commit 58eacfffc417 ("init, tracing: instrument > >> security and console initcall trace events") since security init calls > >> are about to no longer resemble regular init calls. > > > > I'm not against the change, but how much are they going to "no longer > > resemble regular init calls"? > > My take on "regular" init calls is that they're always run, link-time > ordered, etc. The changes proposed here will make it so not all > initialization are run depending on runtime configurations, ordering > will be flexible, etc. > Will it still be a good idea to have a tracepoint for those calls? Perhaps not an initcall tracepoint but some other kind? -- Steve
On Sun, Sep 30, 2018 at 4:25 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > On Wed, 26 Sep 2018 11:35:21 -0700 > Kees Cook <keescook@chromium.org> wrote: > >> On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt <rostedt@goodmis.org> wrote: >> > On Mon, 24 Sep 2018 17:18:07 -0700 >> > Kees Cook <keescook@chromium.org> wrote: >> > >> >> This partially reverts commit 58eacfffc417 ("init, tracing: instrument >> >> security and console initcall trace events") since security init calls >> >> are about to no longer resemble regular init calls. >> > >> > I'm not against the change, but how much are they going to "no longer >> > resemble regular init calls"? >> >> My take on "regular" init calls is that they're always run, link-time >> ordered, etc. The changes proposed here will make it so not all >> initialization are run depending on runtime configurations, ordering >> will be flexible, etc. >> > > Will it still be a good idea to have a tracepoint for those calls? > Perhaps not an initcall tracepoint but some other kind? I'm not opposed. It could be a follow-up patch, I assume? -Kees
On 09/24/2018 05:18 PM, Kees Cook wrote: > This partially reverts commit 58eacfffc417 ("init, tracing: instrument > security and console initcall trace events") since security init calls > are about to no longer resemble regular init calls. > > Cc: James Morris <jmorris@namei.org> > Cc: "Serge E. Hallyn" <serge@hallyn.com> > Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca> > Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> > Cc: linux-security-module@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: John Johansen <john.johansen@canonical.com> though I do think it would be a good idea to add a new set of trace points, but that can come as a separate patch > --- > security/security.c | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/security/security.c b/security/security.c > index 892fe6b691cf..41a5da2c7faf 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -30,8 +30,6 @@ > #include <linux/string.h> > #include <net/flow.h> > > -#include <trace/events/initcall.h> > - > #define MAX_LSM_EVM_XATTR 2 > > /* Maximum number of letters for an LSM name string */ > @@ -47,17 +45,13 @@ static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] = > > static void __init do_security_initcalls(void) > { > - int ret; > initcall_t call; > initcall_entry_t *ce; > > ce = __start_lsm_info; > - trace_initcall_level("security"); > while (ce < __end_lsm_info) { > call = initcall_from_entry(ce); > - trace_initcall_start(call); > - ret = call(); > - trace_initcall_finish(call, ret); > + call(); > ce++; > } > } >
On Mon, 1 Oct 2018 14:07:55 -0700 John Johansen <john.johansen@canonical.com> wrote: > On 09/24/2018 05:18 PM, Kees Cook wrote: > > This partially reverts commit 58eacfffc417 ("init, tracing: instrument > > security and console initcall trace events") since security init calls > > are about to no longer resemble regular init calls. > > > > Cc: James Morris <jmorris@namei.org> > > Cc: "Serge E. Hallyn" <serge@hallyn.com> > > Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca> > > Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> > > Cc: linux-security-module@vger.kernel.org > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > Reviewed-by: John Johansen <john.johansen@canonical.com> > > though I do think it would be a good idea to add a new set > of trace points, but that can come as a separate patch > > Agreed. -- Steve
On Mon, Oct 1, 2018 at 2:23 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > On Mon, 1 Oct 2018 14:07:55 -0700 > John Johansen <john.johansen@canonical.com> wrote: > >> On 09/24/2018 05:18 PM, Kees Cook wrote: >> > This partially reverts commit 58eacfffc417 ("init, tracing: instrument >> > security and console initcall trace events") since security init calls >> > are about to no longer resemble regular init calls. >> > >> > Cc: James Morris <jmorris@namei.org> >> > Cc: "Serge E. Hallyn" <serge@hallyn.com> >> > Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca> >> > Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> >> > Cc: linux-security-module@vger.kernel.org >> > Signed-off-by: Kees Cook <keescook@chromium.org> >> >> >> Reviewed-by: John Johansen <john.johansen@canonical.com> >> >> though I do think it would be a good idea to add a new set >> of trace points, but that can come as a separate patch >> >> > > Agreed. BTW, how would this look? I'm not familiar with adding new tracepoints... -Kees
diff --git a/security/security.c b/security/security.c index 892fe6b691cf..41a5da2c7faf 100644 --- a/security/security.c +++ b/security/security.c @@ -30,8 +30,6 @@ #include <linux/string.h> #include <net/flow.h> -#include <trace/events/initcall.h> - #define MAX_LSM_EVM_XATTR 2 /* Maximum number of letters for an LSM name string */ @@ -47,17 +45,13 @@ static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] = static void __init do_security_initcalls(void) { - int ret; initcall_t call; initcall_entry_t *ce; ce = __start_lsm_info; - trace_initcall_level("security"); while (ce < __end_lsm_info) { call = initcall_from_entry(ce); - trace_initcall_start(call); - ret = call(); - trace_initcall_finish(call, ret); + call(); ce++; } }
This partially reverts commit 58eacfffc417 ("init, tracing: instrument security and console initcall trace events") since security init calls are about to no longer resemble regular init calls. Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> --- security/security.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)