[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200324160616.GA9173@chromium.org>
Date: Tue, 24 Mar 2020 17:06:16 +0100
From: KP Singh <kpsingh@...omium.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: open list <linux-kernel@...r.kernel.org>,
bpf <bpf@...r.kernel.org>, linux-security-module@...r.kernel.org,
Brendan Jackman <jackmanb@...gle.com>,
Florent Revest <revest@...gle.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
James Morris <jmorris@...ei.org>,
Kees Cook <keescook@...omium.org>,
Paul Turner <pjt@...gle.com>, Jann Horn <jannh@...gle.com>,
Florent Revest <revest@...omium.org>,
Brendan Jackman <jackmanb@...omium.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH bpf-next v5 2/7] security: Refactor declaration of LSM
hooks
On 23-Mär 12:56, Andrii Nakryiko wrote:
> On Mon, Mar 23, 2020 at 9:45 AM KP Singh <kpsingh@...omium.org> wrote:
> >
> > From: KP Singh <kpsingh@...gle.com>
> >
> > The information about the different types of LSM hooks is scattered
> > in two locations i.e. union security_list_options and
> > struct security_hook_heads. Rather than duplicating this information
> > even further for BPF_PROG_TYPE_LSM, define all the hooks with the
> > LSM_HOOK macro in lsm_hook_names.h which is then used to generate all
> > the data structures required by the LSM framework.
> >
> > Signed-off-by: KP Singh <kpsingh@...gle.com>
> > Reviewed-by: Brendan Jackman <jackmanb@...gle.com>
> > Reviewed-by: Florent Revest <revest@...gle.com>
> > ---
> > include/linux/lsm_hook_names.h | 354 +++++++++++++++++++
> > include/linux/lsm_hooks.h | 622 +--------------------------------
> > 2 files changed, 360 insertions(+), 616 deletions(-)
> > create mode 100644 include/linux/lsm_hook_names.h
> >
> > diff --git a/include/linux/lsm_hook_names.h b/include/linux/lsm_hook_names.h
> > new file mode 100644
> > index 000000000000..412e4ca24c9b
> > --- /dev/null
> > +++ b/include/linux/lsm_hook_names.h
>
> It's not really just hook names, it's full hook definitions, no? So
> lsm_hook_defs.h seems a bit more appropriate. Just for consideration,
> not that I care that strongly :)
I like lsm_hook_defs.h better too :) Updated.
- KP
>
>
> [...]
Powered by blists - more mailing lists