[PATCH 0/3] Firmware LSM hook

[Leon Romanovsky]

On Wed, Mar 11, 2026 at 12:06:09PM -0400, Paul Moore wrote:
> On Wed, Mar 11, 2026 at 4:20 AM Leon Romanovsky <leon at kernel.org> wrote:
> > On Tue, Mar 10, 2026 at 05:40:02PM -0400, Paul Moore wrote:
> > > 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,
> >
> > I believe this approach offers the cleanest and most natural way to support
> > all mailbox‑based devices.
> >
> > > 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.
> >
> > This suggestion adds an extra call from the FW to the LSM for every command, even
> > for systems which don't have LSM at all.
> 
> If latency is a concern, I imagine we could create an LSM hook to
> report whether any LSMs provided firmware access controls.  The
> firmware could then use that hook, potentially caching the result, to
> limit its calls into the LSM.
> 
> > The FW must pass the already parsed data
> > back to the LSM; otherwise, the LSM   has no basis to decide whether to accept or
> > reject the request.
> >
> > For example, consider the MLX5_CMD_OP_QUERY_DCT command handled in
> > mlx5ctl_validate_rpc(). DCT in RDMA refers to Dynamically Connected
> > Transport, a Mellanox-specific extension that effectively introduces a new
> > QP‑type family on top of the standard RC/UC/UD transports. This type does not
> > exist for other vendors, each of whom provides its own vendor‑specific
> > extensions. All parameters here are tightly coupled to those specific
> > commands.
> >
> > It is unrealistic to expect different firmware implementations to supply
> > their data in a common format that would allow the LSM to make a generic
> > decision.
> 
> That's unfortunate as that would be the easiest path forward.
> Regardless, you are welcome to work on whatever implementation you
> think makes sense for any of the in-tree LSMs, with that in place we
> can take another look at the firmware command hooks.
> 
> Good luck.

I'll take advantage of the upcoming weekend and look into what can be done
here.

Thanks

> 
> -- 
> paul-moore.com