On Wed, Mar 18, 2026 at 10:49 AM Frederick Lawler <[email protected]> wrote: > > Hi Alexei, > > On Tue, Mar 17, 2026 at 06:15:59PM -0700, Alexei Starovoitov wrote: > > On Mon, Mar 16, 2026 at 7:44 PM Kumar Kartikeya Dwivedi > > <[email protected]> wrote: > > > > > > On Wed, 11 Mar 2026 at 22:31, Frederick Lawler <[email protected]> > > > wrote: > > > > > > > > The motivation behind the change is to give BPF LSM developers the > > > > ability to report accesses via the audit subsystem much like how LSMs > > > > operate today. > > > > Sure, but bpf lsm-s don't need to follow such conventions. > > audit is nothing but a message passing from kernel to user space > > and done in a very inefficient way by wrapping strings into skb/netlink. > > bpf progs can do this message passing already via various ways: > > perfbuf, ringbuf, streams. > > Teach your user space to consume one of them. > > Audit provides additional functionality by keeping messages close to the > syscall, and in-line with other messages for that syscall. Aside from > that, BPF is arguably too flexible. I'm sure it's already understood, > but the idea here is to reduce bespoke logging implementations and reduce > attack surface for violation reporting. Audit is already provided by the > kernel and a well leveraged pipeline.
Sorry, I don't buy any of these arguments. Nack.
