From: Paolo Abeni <pabeni@redhat.com>
To: Paul Moore <paul@paul-moore.com>, KP Singh <kpsingh@kernel.org>
Cc: 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, 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: Wed, 26 Jul 2023 13:07:05 +0200 [thread overview]
Message-ID: <a9b4571021004affc10cb5e01a985636bd3e71f1.camel@redhat.com> (raw)
In-Reply-To: <CAHC9VhSqGtZFXn-HW5pfUub4TmU7cqFWWKekL1M+Ko+f5qgi1Q@mail.gmail.com>
Hi all,
On Tue, 2023-06-20 at 19:40 -0400, Paul Moore wrote:
> On Tue, Jun 13, 2023 at 6:03 PM KP Singh <kpsingh@kernel.org> wrote:
> > I tried proposing an idea in
> > https://patchwork.kernel.org/project/netdevbpf/patch/20220609234601.2026362-1-kpsingh@kernel.org/
> > as an LSM_HOOK_NO_EFFECT but that did not seemed to have stuck.
>
> It looks like this was posted about a month before I became
> responsible for the LSM layer as a whole, and likely was lost (at
> least on the LSM side of things) as a result.
>
> I would much rather see a standalone fix to address the unintended LSM
> interactions, then the static call performance improvements in a
> separate patchset.
Please allow me to revive this old thread. I learned about this effort
only recently and I'm interested into it.
Looking at patch 4/4 from this series, it *think* it's doable to
extract it from the series and make it work standalone. If so, would
that approach be ok from a LSM point of view?
One thing that I personally don't understand in said patch is how the
'__ro_after_init' annotation for the bpf_lsm_hooks fits the run-time
'default_state' changes?!?
Cheers,
Paolo
next prev parent reply other threads:[~2023-07-26 11:07 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
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 [this message]
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=a9b4571021004affc10cb5e01a985636bd3e71f1.camel@redhat.com \
--to=pabeni@redhat.com \
--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 \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox