[PATCH 0/3] Firmware LSM hook

[Leon Romanovsky]

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:
 * 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.

Here we propose a generic interface that can be applied to all FWCTL
devices without out-of-tree kernel code at all.

Thanks

> 
> (If you lose the link, or simply for future reference, you can find it
> in the "SECURITY SUBSYSTEM" MAINTAINERS entry.)
> 
> -- 
> paul-moore.com
>