[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4Bza67kM0KiX464yB+iV83aV96TyD7iLEZJccXyH-Od0QTQ@mail.gmail.com>
Date: Mon, 23 Mar 2020 12:56:37 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: KP Singh <kpsingh@...omium.org>
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 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 :)
[...]
Powered by blists - more mailing lists