On Wed, May 7, 2025 at 1:48 PM James Bottomley James.Bottomley@hansenpartnership.com wrote:
I'm with Paul on this: if you could share your design ideas more fully than you have above that would help make this debate way more technical.
I think it would also help some of us, at the very least me, put your objections into context. I believe the more durable solutions that end up in Linus' tree are combinations of designs created out of compromise, and right now we are missing the context and detail of your ideal solution to be able to do that compromise and get to a design and implementation we can all begrudgingly accept. In the absence of a detailed alternate design, and considering that BPF signature validation efforts have sputtered along for years without any real success, we'll continue to push forward on-list with refinements to the current proposal in an effort to drive this to some form of resolution.
I also get the impression that there might be a disagreement over scope: what seems to be coming out of BPF is that every signing problem and scenario must be solved before signing can be considered acceptable; however, I think it's not unreasonable to attempt to cover a portion of the use cases and allow for future additions of things like policy so we can get some forward motion to allow others to play with it and produce patches based on their use cases.
Beyond any potential future updates to Hornet, I just wanted to make it clear that the Hornet LSM approach, like any LSM, can be disabled both at compile time for those users who build their own kernels, as well as at kernel boot time using the "lsm=" command line option for those who are limited to pre-built kernels, e.g. distro kernels. Users can always disable Hornet and replace it with another LSM, either a BPF LSM or a native/C LSM, of their choosing; the LSM framework is intentionally flexible to allow for this substitution and replacement, with plenty of existing examples already.