All of lore.kernel.org
 help / color / mirror / Atom feed
From: Song Liu <song@kernel.org>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: KP Singh <kpsingh@kernel.org>, Kees Cook <keescook@chromium.org>,
	linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
	ast@kernel.org, daniel@iogearbox.net, jackmanb@google.com,
	renauld@google.com, paul@paul-moore.com, revest@chromium.org
Subject: Re: [PATCH RESEND bpf-next 3/4] security: Replace indirect LSM hook calls with static calls
Date: Mon, 6 Feb 2023 11:05:28 -0800	[thread overview]
Message-ID: <CAPhsuW5RiduusLJFTcj6p78aMsv7_XhepvptN7CG+9oV8oHSiA@mail.gmail.com> (raw)
In-Reply-To: <8b5f62f3-a2c4-9ba3-d1e4-af557047f44b@schaufler-ca.com>

On Mon, Feb 6, 2023 at 10:29 AM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
[...]
> >>> I should have added it in the commit description, actually we are
> >>> optimizing for "hot paths are less likely to have LSM hooks enabled"
> >>> (eg. socket_sendmsg).
> >> How did you come to that conclusion? Where is there a correlation between
> >> "hot path" and "less likely to be enabled"?
> > I could echo KP's reasoning here. AFAICT, the correlation is that LSMs on
> > hot path will give more performance overhead. In our use cases (Meta),
> > we are very careful with "small" performance hits. 0.25% is significant
> > overhead; 1% overhead will not fly without very good reasons (Do we
> > have to do this? Are there any other alternatives?). If it is possible to
> > achieve similar security on a different hook, we will not enable the hook on
> > the hot path. For example, we may not enable socket_sendmsg, but try
> > to disallow opening such sockets instead.
>
> I'm not asking about BPF. I'm asking about the impact on other LSMs.
> If you're talking strictly about BPF you need to say that. I'm all for
> performance improvement. But as I've said before, it should be for all
> the security modules, not just BPF.

I don't think anything here is BPF specific. Performance-security tradeoff
should be the same for all LSMs. A hook on the hot path is more expensive
than a hook on a cooler path. This is the same for all LSMs, no?

Thanks,
Song

  parent reply	other threads:[~2023-02-06 19:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20  0:08 [PATCH RESEND bpf-next 0/4] Reduce overhead of LSMs with static calls KP Singh
2023-01-20  0:08 ` [PATCH RESEND bpf-next 1/4] kernel: Add helper macros for loop unrolling KP Singh
2023-01-20  3:48   ` Kees Cook
2023-01-20  0:08 ` [PATCH RESEND bpf-next 2/4] security: Generate a header with the count of enabled LSMs KP Singh
2023-01-20  4:04   ` Kees Cook
2023-01-20  7:33   ` kernel test robot
2023-01-20  9:50   ` kernel test robot
2023-01-20  9:50   ` kernel test robot
2023-01-20  0:08 ` [PATCH RESEND bpf-next 3/4] security: Replace indirect LSM hook calls with static calls KP Singh
2023-01-20  4:36   ` Kees Cook
2023-01-20 18:26     ` Casey Schaufler
2023-02-06 13:04     ` KP Singh
2023-02-06 16:29       ` Casey Schaufler
2023-02-06 17:48         ` Song Liu
2023-02-06 18:19           ` KP Singh
2023-02-06 18:29           ` Casey Schaufler
2023-02-06 18:41             ` KP Singh
2023-02-06 18:50               ` Kees Cook
2023-06-08  2:48                 ` KP Singh
2023-06-13 21:43                   ` Paul Moore
2023-06-13 22:03                     ` KP Singh
2023-02-06 19:05             ` Song Liu [this message]
2023-02-06 20:11               ` Casey Schaufler
2023-01-20 10:10   ` kernel test robot
2023-01-20 10:41   ` kernel test robot
2023-01-20  0:08 ` [PATCH RESEND bpf-next 4/4] bpf: Only enable BPF LSM hooks when an LSM program is attached 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=CAPhsuW5RiduusLJFTcj6p78aMsv7_XhepvptN7CG+9oV8oHSiA@mail.gmail.com \
    --to=song@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=daniel@iogearbox.net \
    --cc=jackmanb@google.com \
    --cc=keescook@chromium.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=renauld@google.com \
    --cc=revest@chromium.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.