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: > > > > > From Chiara: > > > > > > > > > > This patch set introduces a new BPF LSM hook to validate firmware > > > > > commands > > > > > triggered by userspace before they are submitted to the device. The > > > > > hook > > > > > runs after the command buffer is constructed, right before it is sent > > > > > to firmware. > > > > > > > > <...> > > > > > > > > > --- > > > > > Chiara Meiohas (4): > > > > > bpf: add firmware command validation hook > > > > > selftests/bpf: add test cases for fw_validate_cmd hook > > > > > RDMA/mlx5: Externally validate FW commands supplied in DEVX > > > > > interface > > > > > fwctl/mlx5: Externally validate FW commands supplied in fwctl > > > > > > > > Hi, > > > > > > > > Can we get Ack from BPF/LSM side? > > > > > > + Paul, linux-security-module ML > > > > > > Hi > > > > > > probably you also want to get an Ack from the LSM maintainer (added in > > > CC with the list). Most likely, he will also ask you to create the > > > security_*() functions counterparts of the BPF hooks. > > > > 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." > 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. > > 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 > > -- > paul-moore.com >
