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. -- paul-moore.com
