From: Kees Cook <keescook@chromium.org>
To: Paul Moore <paul@paul-moore.com>
Cc: KP Singh <kpsingh@kernel.org>,
linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
ast@kernel.org, daniel@iogearbox.net, jackmanb@google.com,
renauld@google.com, casey@schaufler-ca.com, song@kernel.org,
revest@chromium.org
Subject: Re: [PATCH bpf-next 0/4] Reduce overhead of LSMs with static calls
Date: Thu, 9 Feb 2023 08:56:07 -0800 [thread overview]
Message-ID: <63e525a8.170a0220.e8217.2fdb@mx.google.com> (raw)
In-Reply-To: <CAHC9VhRpsXME9Wht_RuSACuU97k359dihye4hW15nWwSQpxtng@mail.gmail.com>
On Fri, Jan 27, 2023 at 03:16:38PM -0500, Paul Moore wrote:
> On Thu, Jan 19, 2023 at 6:10 PM KP Singh <kpsingh@kernel.org> wrote:
> >
> > # Background
> >
> > LSM hooks (callbacks) are currently invoked as indirect function calls. These
> > callbacks are registered into a linked list at boot time as the order of the
> > LSMs can be configured on the kernel command line with the "lsm=" command line
> > parameter.
>
> Thanks for sending this KP. I had hoped to make a proper pass through
> this patchset this week but I ended up getting stuck trying to wrap my
> head around some network segmentation offload issues and didn't quite
> make it here. Rest assured it is still in my review queue.
>
> However, I did manage to take a quick look at the patches and one of
> the first things that jumped out at me is it *looks* like this
> patchset is attempting two things: fix a problem where one LSM could
> trample another (especially problematic with the BPF LSM due to its
> nature), and reduce the overhead of making LSM calls. I realize that
> in this patchset the fix and the optimization are heavily
> intermingled, but I wonder what it would take to develop a standalone
> fix using the existing indirect call approach? I'm guessing that is
> going to potentially be a pretty significant patch, but if we could
> add a little standardization to the LSM hooks without adding too much
> in the way of code complexity or execution overhead I think that might
> be a win independent of any changes to how we call the hooks.
>
> Of course this could be crazy too, but I'm the guy who has to ask
> these questions :)
Hm, I am expecting this patch series to _not_ change any semantics of
the LSM "stack". I would agree: nothing should change in this series, as
it should be strictly a mechanical change from "iterate a list of
indirect calls" to "make a series of direct calls". Perhaps I missed
a logical change?
--
Kees Cook
next prev parent reply other threads:[~2023-02-09 16:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 23:10 [PATCH bpf-next 0/4] Reduce overhead of LSMs with static calls KP Singh
2023-01-19 23:10 ` [PATCH bpf-next 1/4] kernel: Add helper macros for loop unrolling KP Singh
2023-01-19 23:10 ` [PATCH bpf-next 2/4] security: Generate a header with the count of enabled LSMs KP Singh
2023-01-20 1:32 ` Casey Schaufler
2023-01-20 2:15 ` KP Singh
2023-01-20 18:35 ` Kui-Feng Lee
2023-01-20 19:40 ` Kees Cook
2023-01-19 23:10 ` [PATCH bpf-next 3/4] security: Replace indirect LSM hook calls with static calls KP Singh
2023-01-20 1:43 ` Casey Schaufler
2023-01-20 2:13 ` KP Singh
2023-01-19 23:10 ` [PATCH bpf-next 4/4] bpf: Only enable BPF LSM hooks when an LSM program is attached KP Singh
2023-01-20 1:13 ` [PATCH bpf-next 0/4] Reduce overhead of LSMs with static calls Casey Schaufler
2023-01-20 2:17 ` KP Singh
2023-01-20 18:40 ` Casey Schaufler
2023-01-27 19:22 ` Song Liu
2023-01-27 20:16 ` Paul Moore
2023-02-09 16:56 ` Kees Cook [this message]
2023-02-10 20:03 ` Paul Moore
2023-02-11 2:32 ` Casey Schaufler
2023-02-12 22:00 ` Paul Moore
2023-02-13 18:04 ` Casey Schaufler
2023-02-13 18:29 ` Casey Schaufler
2023-06-13 22:02 ` KP Singh
2023-06-20 23:40 ` Paul Moore
2023-07-26 11:07 ` Paolo Abeni
2023-09-16 0:57 ` KP Singh
2023-09-16 8:06 ` Paolo Abeni
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=63e525a8.170a0220.e8217.2fdb@mx.google.com \
--to=keescook@chromium.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=jackmanb@google.com \
--cc=kpsingh@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=renauld@google.com \
--cc=revest@chromium.org \
--cc=song@kernel.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.