Re: [PATCH bpf-next 0/2] lsm: give BPF programs a way to query locked_down state
Paul Moore <[email protected]>
| Newsgroups | org.kernel.vger.linux-security-module,org.kernel.vger.bpf,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAHC9VhRzfOR4-RtPapOC4am8F=sC54VDzr7hAn2UMxNQwp_38A@mail.gmail.com> |
On Tue, Aug 18, 2026 at 4:16 PM David Windsor <[email protected]> wrote: > On Tue, Aug 18, 2026 at 3:48 PM Paul Moore <[email protected]> wrote: > > On Tue, Aug 18, 2026 at 1:42 PM David Windsor <[email protected]> wrote: > > > On Tue, Aug 18, 2026 at 5:43 AM Kumar Kartikeya Dwivedi > > > <[email protected]> wrote: > > > > > > > > > > > > Lastly, given the difficulties we've faced from the LSM maintainers, I'm not > > > > inclined to waste more time in explaining again why this cannot go under > > > > security/. > > > > > > > > > > I'm still going to send v7 of bpf_init_inode_xattr series, even though > > > it's a stalemate. Haven't yet decided where it'll live in v7, I'm > > > inclined to leave it where it was (in fs/) since one side will NAK it > > > wherever it lives. We can record NAKs and take it from there. > > > > As a FYI, I'm not going to ACK any of the LSM changes with the kfunc > > in security/bpf_lsm_kfuncs.c. > > Hmm, even if it lands in security/ you'd not ACK it? Bah, a typo on my part, my apologies! What I had meant to say was that I'm not going to ACK any of the LSM changes with the kfunc *not* in security/bpf_lsm_kfuncs.c. Sorry for the confusion. -- paul-moore.com