[PATCH 0/3] Firmware LSM hook

[Paul Moore]

On Tue, Mar 10, 2026 at 3:30 PM Leon Romanovsky <leon at kernel.org> wrote:
> On Tue, Mar 10, 2026 at 02:24:40PM -0400, Paul Moore wrote:
> > On Tue, Mar 10, 2026 at 5:07 AM Leon Romanovsky <leon at kernel.org> wrote:
> > > 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:
> >
> > ...
> >
> > > > > > 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.
> >
> > That helps, thank you.
> >
> > > > > 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.
> >
> > Without a standard format, opcode definitions, etc. I suspect
> > integrating this into an LSM will present a number of challenges.
>
> The opcode is relatively easy to extract from the mailbox and pass to the LSM.
> All drivers implement some variant of mlx5ctl_validate_rpc()/devx_is_general_cmd()
> to validate the opcode. The problem is that this check alone is not sufficient.
>
> > Instead of performing an LSM access control check before submitting
> > the firmware command, it might be easier from an LSM perspective to
> > have the firmware call into the kernel/LSM for an access control
> > decision before performing a security-relevant action.
>
> Ultimately, the LSM must make a decision for each executed firmware
> command. This will need to be handled one way or another, and will
> likely require parsing the mailbox again.

As it's unlikely that parsing the mailbox is something that a LSM will
want to handle, my suggestion was to leverage the existing mailbox
parsing in the firmware and require the firmware to call into the LSM
when authorization is needed.

> > This removes the challenge of parsing/interpreting the arbitrary firmware commands,
> > but it does add some additional complexity of having to generically
> > represent the security relevant actions the firmware might request
>
> The difference here is that the proposed LSM hook is intended to disable
> certain functionality provided by the firmware, effectively depending on
> the operator’s preferences.

My suggestion would also allow a LSM hook to disable certain firmware
functionality; however, the firmware itself would need to call the LSM
to check if the functionality is authorized.

-- 
paul-moore.com