[PATCH 0/3] Firmware LSM hook

[Leon Romanovsky]

On Mon, Mar 09, 2026 at 07:10:25PM -0400, Paul Moore wrote:
> On Mon, Mar 9, 2026 at 3:37 PM Leon Romanovsky <leon at kernel.org> wrote:
> > On Mon, Mar 09, 2026 at 02:32:39PM -0400, Paul Moore wrote:
> > > On Mon, Mar 9, 2026 at 7:15 AM Leon Romanovsky <leon at kernel.org> wrote:
> > > >
> > > > From Chiara:
> > > >
> > > > This patch set introduces a new 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.
> > > >
> > > > The goal is to allow a security module to allow or deny a given command
> > > > before it is submitted to firmware. BPF LSM can attach to this hook
> > > > to implement such policies. This allows fine-grained policies for different
> > > > firmware commands.
> > > >
> > > > In this series, the new hook is called from RDMA uverbs and from the fwctl
> > > > subsystem. Both the uverbs and fwctl interfaces use ioctl, so an obvious
> > > > candidate would seem to be the file_ioctl hook. However, the userspace
> > > > attributes used to build the firmware command buffer are copied from
> > > > userspace (copy_from_user()) deep in the driver, depending on various
> > > > conditions. As a result, file_ioctl does not have the information required
> > > > to make a policy decision.
> > > >
> > > > This newly introduced hook provides the command buffer together with relevant
> > > > metadata (device, command class, and a class-specific device identifier), so
> > > > security modules can distinguish between different command classes and devices.
> > > >
> > > > The hook can be used by other drivers that submit firmware commands via a command
> > > > buffer.
> > >
> > > Hi Leon,
> > >
> > > At the link below, you'll find guidance on submitting new LSM hooks.
> > > Please take a look and let me know if you have any questions.
> > >
> > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks
> >
> > I assume that you are referring to this part:
> 
> I'm referring to all of the guidance, but yes, at the very least that
> is something that I think we need to see in a future revision of this
> patchset.
> 
> >  * New LSM hooks must demonstrate their usefulness by providing a meaningful
> >    implementation for at least one in-kernel LSM. The goal is to demonstrate
> >    the purpose and expected semantics of the hooks. Out of tree kernel code,
> >    and pass through implementations, such as the BPF LSM, are not eligible
> >    for LSM hook reference implementations.
> >
> > The point is that we are not inspecting a kernel call, but the FW mailbox,
> > which has very little meaning to the kernel. From the kernel's perspective,
> > all relevant checks have already been performed, but the existing capability
> > granularity does not allow us to distinguish between FW_CMD1 and FW_CMD2.
> 
> It might help if you could phrase this differently, as I'm not
> entirely clear on your argument.  LSMs are not limited to enforcing
> access controls on requests the kernel understands (see the SELinux
> userspace object manager concept), and the idea of access controls
> with greater granularity than capabilities is one of the main reasons
> people look to LSMs for access control (SELinux, AppArmor, Smack,
> etc.).

I should note that my understanding of LSM is limited, so some parts of my
answers may be inaccurate.

What I am referring to is a different level of granularity — specifically,
the internals of the firmware commands. In the proposed approach, BPF
programs would make decisions based on data passed through the mailbox.
That mailbox format varies across vendors, and may even differ between
firmware versions from the same vendor.

> 
> > Here we propose a generic interface that can be applied to all FWCTL
> > devices without out-of-tree kernel code at all.
> 
> I expected to see a patch implementing some meaningful support for
> access controls using these hooks in one of the existing LSMs, I did
> not see that in this patchset.

In some cases, the mailbox is forwarded from user space unchanged, but
in others the kernel modifies it before submitting it to the FW.

For example, at line 1140 we update the UID field, which indicates the
process to which the request belongs. This field is managed by the
kernel to ensure that user processes cannot access FW internals of other
processes.

1108 static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OTHER)( 
1109         struct uverbs_attr_bundle *attrs)            
1110 {                                                   
1111         struct mlx5_ib_ucontext *c;                
1112         struct mlx5_ib_dev *dev;                  
1113         void *cmd_in = uverbs_attr_get_alloced_ptr( 
1114                 attrs, MLX5_IB_ATTR_DEVX_OTHER_CMD_IN);

<...>

1121         int uid; 

<...>

1128         uid = devx_get_uid(c, cmd_in); 
1129         if (uid < 0)
1130                 return uid;                                                                                                                                                                              

<...>

1140         MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid); 
1141         err = security_fw_validate_cmd(cmd_in, cmd_in_len, &dev->ib_dev.dev, 
1142                                        FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
1143         if (err)
1144                 return err; 
1145                            
1146         err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out, cmd_out_len);      

Could you point me to the LSM that would be best suited for performing  
checks of this kind?

Thanks

> 
> --
> paul-moore.com