linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>
Cc: "Jann Horn" <jannh@google.com>, "KP Singh" <kpsingh@chromium.org>,
	"kernel list" <linux-kernel@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	"Brendan Jackman" <jackmanb@google.com>,
	"Florent Revest" <revest@google.com>,
	"Thomas Garnier" <thgarnie@google.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"James Morris" <jmorris@namei.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Thomas Garnier" <thgarnie@chromium.org>,
	"Michael Halcrow" <mhalcrow@google.com>,
	"Paul Turner" <pjt@google.com>,
	"Brendan Gregg" <brendan.d.gregg@gmail.com>,
	"Matthew Garrett" <mjg59@google.com>,
	"Christian Brauner" <christian@brauner.io>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Florent Revest" <revest@chromium.org>,
	"Brendan Jackman" <jackmanb@chromium.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Mauro Carvalho Chehab" <mchehab+samsung@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Kernel Team" <kernel-team@fb.com>,
	"Casey Schaufler" <casey@schaufler-ca.com>
Subject: Re: BPF LSM and fexit [was: [PATCH bpf-next v3 04/10] bpf: lsm: Add mutable hooks list for the BPF LSM]
Date: Wed, 12 Feb 2020 07:52:09 -0800	[thread overview]
Message-ID: <bee0fd08-b9f2-83e4-2882-475b81c74303@schaufler-ca.com> (raw)
In-Reply-To: <20200212024542.gdsafhvqykucdp4h@ast-mbp>

On 2/11/2020 6:45 PM, Alexei Starovoitov wrote:
> On Wed, Feb 12, 2020 at 01:09:07AM +0100, Daniel Borkmann wrote:
>> Another approach could be to have a special nop inside call_int_hook()
>> macro which would then get patched to avoid these situations. Somewhat
>> similar like static keys where it could be defined anywhere in text but
>> with updating of call_int_hook()'s RC for the verdict.

Tell me again why you can't register your BPF hooks like all the
other security modules do? You keep reintroducing BPF as a special
case, and I don't see why.

> Sounds nice in theory. I couldn't quite picture how that would look
> in the code, so I hacked:
> diff --git a/security/security.c b/security/security.c
> index 565bc9b67276..ce4bc1e5e26c 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -28,6 +28,7 @@
>  #include <linux/string.h>
>  #include <linux/msg.h>
>  #include <net/flow.h>
> +#include <linux/jump_label.h>
>
>  #define MAX_LSM_EVM_XATTR      2
>
> @@ -678,12 +679,26 @@ static void __init lsm_early_task(struct task_struct *task)
>   *     This is a hook that returns a value.
>   */
>
> +#define LSM_HOOK_NAME(FUNC) \
> +       DEFINE_STATIC_KEY_FALSE(bpf_lsm_key_##FUNC);
> +#include <linux/lsm_hook_names.h>
> +#undef LSM_HOOK_NAME
> +__diag_push();
> +__diag_ignore(GCC, 8, "-Wstrict-prototypes", "");
> +#define LSM_HOOK_NAME(FUNC) \
> +       int bpf_lsm_call_##FUNC() {return 0;}
> +#include <linux/lsm_hook_names.h>
> +#undef LSM_HOOK_NAME
> +__diag_pop();
> +
>  #define call_void_hook(FUNC, ...)                              \
>         do {                                                    \
>                 struct security_hook_list *P;                   \
>                                                                 \
>                 hlist_for_each_entry(P, &security_hook_heads.FUNC, list) \
>                         P->hook.FUNC(__VA_ARGS__);              \
> +               if (static_branch_unlikely(&bpf_lsm_key_##FUNC)) \
> +                      (void)bpf_lsm_call_##FUNC(__VA_ARGS__); \
>         } while (0)
>
>  #define call_int_hook(FUNC, IRC, ...) ({                       \
> @@ -696,6 +711,8 @@ static void __init lsm_early_task(struct task_struct *task)
>                         if (RC != 0)                            \
>                                 break;                          \
>                 }                                               \
> +               if (RC == IRC && static_branch_unlikely(&bpf_lsm_key_##FUNC)) \
> +                      RC = bpf_lsm_call_##FUNC(__VA_ARGS__); \
>         } while (0);                                            \
>         RC;                                                     \
>  })
>
> The assembly looks good from correctness and performance points.
> union security_list_options can be split into lsm_hook_names.h too
> to avoid __diag_ignore. Is that what you have in mind?
> I don't see how one can improve call_int_hook() macro without
> full refactoring of linux/lsm_hooks.h
> imo static_key doesn't have to be there in the first set. We can add this
> optimization later.

  parent reply	other threads:[~2020-02-12 15:52 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23 15:24 [PATCH bpf-next v3 00/10] MAC and Audit policy using eBPF (KRSI) KP Singh
2020-01-23 15:24 ` [PATCH bpf-next v3 01/10] bpf: btf: Add btf_type_by_name_kind KP Singh
2020-01-23 20:06   ` Andrii Nakryiko
2020-01-24 14:12     ` KP Singh
2020-01-23 15:24 ` [PATCH bpf-next v3 02/10] bpf: lsm: Add a skeleton and config options KP Singh
2020-02-10 23:52   ` Alexei Starovoitov
2020-02-11 12:45     ` KP Singh
2020-01-23 15:24 ` [PATCH bpf-next v3 03/10] bpf: lsm: Introduce types for eBPF based LSM KP Singh
2020-02-10 23:58   ` Alexei Starovoitov
2020-02-11 12:44     ` KP Singh
2020-01-23 15:24 ` [PATCH bpf-next v3 04/10] bpf: lsm: Add mutable hooks list for the BPF LSM KP Singh
2020-01-23 17:03   ` Casey Schaufler
2020-01-23 17:59     ` KP Singh
2020-01-23 19:09       ` Casey Schaufler
2020-01-23 22:24         ` KP Singh
2020-01-23 23:50           ` Casey Schaufler
2020-01-24  1:25             ` KP Singh
2020-01-24 21:55               ` James Morris
2020-02-11  3:12   ` Alexei Starovoitov
2020-02-11 12:43     ` KP Singh
2020-02-11 17:58       ` Alexei Starovoitov
2020-02-11 18:44         ` BPF LSM and fexit [was: [PATCH bpf-next v3 04/10] bpf: lsm: Add mutable hooks list for the BPF LSM] Jann Horn
2020-02-11 19:09           ` Alexei Starovoitov
2020-02-11 19:36             ` Jann Horn
2020-02-11 20:10               ` Alexei Starovoitov
2020-02-11 20:33                 ` Jann Horn
2020-02-11 21:32                   ` Jann Horn
2020-02-11 21:38                   ` Alexei Starovoitov
2020-02-11 23:26                     ` Alexei Starovoitov
2020-02-12  0:09                       ` Daniel Borkmann
2020-02-12  2:45                         ` Alexei Starovoitov
2020-02-12 13:27                           ` Daniel Borkmann
2020-02-12 16:04                             ` KP Singh
2020-02-12 15:52                           ` Casey Schaufler [this message]
2020-02-12 16:26                             ` KP Singh
2020-02-12 18:59                               ` Casey Schaufler
2020-01-23 15:24 ` [PATCH bpf-next v3 05/10] bpf: lsm: BTF API for LSM hooks KP Singh
2020-01-23 15:24 ` [PATCH bpf-next v3 06/10] bpf: lsm: Implement attach, detach and execution KP Singh
2020-01-23 15:24 ` [PATCH bpf-next v3 07/10] bpf: lsm: Make the allocated callback RO+X KP Singh
2020-01-23 15:24 ` [PATCH bpf-next v3 08/10] tools/libbpf: Add support for BPF_PROG_TYPE_LSM KP Singh
2020-01-23 18:00   ` Andrii Nakryiko
2020-01-24 14:16     ` KP Singh
2020-01-23 15:24 ` [PATCH bpf-next v3 09/10] bpf: lsm: Add selftests " KP Singh
2020-01-23 15:24 ` [PATCH bpf-next v3 10/10] bpf: lsm: Add Documentation KP Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bee0fd08-b9f2-83e4-2882-475b81c74303@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brendan.d.gregg@gmail.com \
    --cc=christian@brauner.io \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jackmanb@chromium.org \
    --cc=jackmanb@google.com \
    --cc=jannh@google.com \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=kernel-team@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mchehab+samsung@kernel.org \
    --cc=mhalcrow@google.com \
    --cc=mic@digikod.net \
    --cc=mjg59@google.com \
    --cc=pjt@google.com \
    --cc=revest@chromium.org \
    --cc=revest@google.com \
    --cc=serge@hallyn.com \
    --cc=thgarnie@chromium.org \
    --cc=thgarnie@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).