Re: [PATCH bpf-next 0/2] lsm: give BPF programs a way to query locked_down state

[Justin Suess <utilityemal77@gmail.com>]

On Tue, Aug 18, 2026 at 11:42:34AM +0200, Kumar Kartikeya Dwivedi wrote:
> On Sat Aug 15, 2026 at 1:20 PM CEST, Justin Suess wrote:
> 
> If you care about knowing the state of lockdown LSM, doing
> bpf_probe_read_kernel() etc. should allow reading that state from the program.
> If you have a BPF LSM supplying a dynamic verdict in your environment, I don't
> see why you cannot use the decision procedure from the same implementation in
> other places of the LSM. I doubt you have the scenario where BPF LSM is shipped
> by someone else and your program needs access to its decisions instead.
> 
(I've found a workaround with tracepoints that removes the need for this
series. Thank you anyway)
> 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/.
>
Without wanting to rehash this issue,

Both LSM and BPF maintainers, some cc'd in the thread, have worked with me as a
new contributor through my mistakes and volunteered their time, expertise, and effort.
I cannot appreciate it enough.

Clearly, great talent and commitment to making the kernel better lives on both sides of the fence.
There's also no question the whole kernel would benefit from better communication between these
awesome subsystems.

I don't mean to admonish anyone or assign fault. Debates happen, things get heated,
it's what happens. But the fact that multiple series are stalled on this because BPF/LSM
don't trust each other enough to have shared code ownership implies the current process
is broken. This isn't the first instance of this breakdown either. It hurts new
contributors caught in the crossfire, maintainers who have to tiptoe around this drama, and 
kernel users.

If anyone is willing: I'd like to set the debates aside and discuss in good faith how we can
establish a better process for LSM/BPF review, testing, and integration. So we can steer this
conversation to the technical side, which is where actual work happens.

That could be an LSM/BPF integration branch, or Documentation/, or something else, or
meeting up at a conference and having some beers together.

Kind Regards,
Justin

> pw-bot: cr
> 
> > [...]