[PATCH 0/3] Firmware LSM hook

[Paul Moore]

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.).

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

--
paul-moore.com