On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote: > On Sun, Apr 12, 2026 at 5:00 AM Leon Romanovsky <[email protected]> wrote: > > On Thu, Apr 09, 2026 at 05:04:24PM -0400, Paul Moore wrote: > > > On Thu, Apr 9, 2026 at 8:45 AM Leon Romanovsky <[email protected]> wrote: > > > > On Thu, Apr 09, 2026 at 02:27:43PM +0200, Roberto Sassu wrote: > > > > > On Thu, 2026-04-09 at 15:12 +0300, Leon Romanovsky wrote: > > > > > > On Tue, Mar 31, 2026 at 08:56:32AM +0300, Leon Romanovsky wrote: > > ... > > > > > We implemented this approach in v1: > > > > https://patch.msgid.link/[email protected] > > > > and were advised to pursue a different direction. > > > > > > I'm assuming you are referring to my comments? If so, that isn't exactly > > > what I said, > > > I mentioned at least one other option besides > > > going directly to BPF. Ultimately, it is your choice to decide how > > > you want to proceed, but to claim I advised you to avoid a LSM based > > > solution isn't strictly correct. > > > > Yes, this matches how we understood your comments: > > https://lore.kernel.org/all/20260311081955.GS12611@unreal/ > > > > In the end, the goal is to build something practical and avoid adding > > unnecessary complexity that brings no real benefit to users. > > > > > Regardless, looking at your v2 patchset, it looks like you've taken an > > > unusual approach of using some of the LSM mechanisms, e.g. LSM_HOOK(), > > > but not actually exposing a LSM hook with proper callbacks. > > > Unfortunately, that's not something we want to support. If you want > > > to pursue an LSM based solution, complete with a security_XXX() hook, > > > use of LSM_HOOK() macros, etc. then that's fine, I'm happy to work > > > with you on that. > > > > The issue is that the sentence below was the reason we did not merge v1 > > with v2: > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks > > "pass through implementations, such as the BPF LSM, are not eligible for > > LSM hook reference implementations." > > I can expand on that in a minute, but I'd like to return to your use > of the LSM_HOOK() macro and locating the hook within the BPF LSM as > that is the most concerning issue from my perspective. One should > only use the LSM_HOOK() macro and locate code within bpf_lsm.c if that > code is part of the BPF LSM, utilizing an LSM hook. Since this > patchset doesn't use an LSM hook or any part of the LSM framework, the > implementation choices seem odd and are not something we want to > support. As mentioned in my prior reply, you could do something very > similar though the use of a normal BPF hook similar to what was done > with the update_socket_protocol() BPF hook. > > There are multiple reasons why out-of-tree and pass through LSMs are > not considered eligible for reference implementations of LSM hooks. I > think is most relevant to this patchset is that an out-of-tree hook > implementation doesn't necessarily require a stable interface, and > without a stable interface it is impossible to make a generic API at > the LSM framework layer. As you mentioned previously, each vendor and > each firmware version brings the possibility of a new > format/interface, and while that may not be a problem for out-of-tree > code which is left to the user/admin to manage, it makes upstream > development difficult. I did mention at least one approach that might > be a possibility to enable upstream, in-tree support of this, but you > seem to prefer a BPF approach that doesn't require a well defined > format. > > > > However, if you've decided that your preferred > > > option is to create a BPF hook you should avoid using things like > > > LSM_HOOK() and locating your hook/code in bpf_lsm.c. > > > > We are not limited to LSM solution, the goal is to intercept commands > > which are submitted to the FW and "security" bucket sounded right to us. > > Yes, it does sound "security relevant", but without a well defined > interface/format it is going to be difficult to write a generic LSM to > have any level of granularity beyond a basic "load firmware" > permission. > > > > The good news is that there are plenty of other examples of BPF > > > plugable code that you could use as an example, one such thing is the > > > update_socket_protocol() BPF hook that was originally proposed as a > > > LSM hook, but moved to a dedicated BPF hook as we generally want to > > > avoid changing non-LSM kernel objects within the scope of the LSMs. > > > While your proposed case is slightly different, I think the basic idea > > > and mechanism should still be useful. > > > > > > https://lore.kernel.org/all/[email protected] > > > > Thanks > > Good luck on whatever you choose, and while I'm guessing it is > unlikely, if you do decide to pursue a LSM based solution please let > us know and we can work with you to try and find ways to make it work.
Thanks a lot. We should know which direction we'll take in a week or two, once Chiara wraps up her internal commitments and returns to this series. I appreciate your help. Thanks > > -- > paul-moore.com >
