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