[PATCH v2 0/4] Firmware LSM hook

[Paul Moore]

On Mon, Apr 13, 2026 at 7:19 PM Jason Gunthorpe <jgg at ziepe.ca> wrote:
> On Mon, Apr 13, 2026 at 06:36:06PM -0400, Paul Moore wrote:
> > On Mon, Apr 13, 2026 at 12:42 PM Jason Gunthorpe <jgg at ziepe.ca> wrote:
> > > On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote:
> > > > > We are not limited to LSM solution, the goal is to intercept commands
> > > > > which are submitted to the FW and "security" bucket sounded right to us.
> > > >
> > > > Yes, it does sound "security relevant", but without a well defined
> > > > interface/format it is going to be difficult to write a generic LSM to
> > > > have any level of granularity beyond a basic "load firmware"
> > > > permission.
> > >
> > > I think to step back a bit, what this is trying to achieve is very
> > > similar to the iptables fwmark/secmark scheme.
> >
> > Points for thinking outside the box a bit, but from what I've seen
> > thus far, it differs from secmark in a few important areas.  The
> > secmark concept relies on the admin to configure the network stack to
> > apply secmark labels to network traffic as it flows through the
> > system, the LSM then applies security policy to these packets based on
> > their label.  The firmware LSM hooks, at least as I currently
> > understand them, rely on the LSM hook callback to parse the firmware
> > op/request and apply a security policy to the request.
>
> That was what was proposed because the idea was to combine the
> parse/clasification/decision steps into one eBPF program, but I think
> it can be split up too.
>
> > We've already talked about the first issue, parsing the request, and
> > my suggestion was to make the LSM hook call from within the firmware
> > (the firmware must have some way to call into the kernel/driver code,
> > no?)
>
> No, that's not workable on so many levels. It is sort of anaologous to
> asking the NIC to call the LSM to apply the secmark while sending the
> packet.

>From the LSM's perspective it really doesn't matter who calls the LSM
hook as long as the caller can be trusted to handle the access control
verdict properly.

> The proper flow has the kernel evaluate the packet/command *before* it
> delivers it to HW, not after.

>From what I can see that's an artificial constraint since we've
already chosen to trust the device.  After all, if we don't trust the
device, why are we talking to it?

> > so that only the firmware would need to parse the request.  If we
> > wanted to adopt a secmark-esque approach, one could develop a second
> > parsing mechanism that would be responsible for assigning a LSM label
> > to the request, and then pass the firmware request to the LSM, but I
> > do worry a bit about the added complexity associated with keeping the
> > parser sync'd with the driver/fw.
>
> In practice it would be like iptables, the parser would be entirely
> programmed by userspace and there is nothing to keep in sync.

You've mentioned a few times now that the firmware/request will vary
across not only devices, but firmware revisions too, this implies
there will need to be some effort to keep whatever parser you develop
(BPF, userspace config, etc.) in sync with the parser built into the
firmware.  Or am I misunderstanding something?

> > However, even if we solve the parsing problem, I worry we have
> > another, closely related issue, of having to categorize all of the
> > past, present, and future firmware requests into a set of LSM specific
> > actions.
>
> Why? secmark doesn't have this issue? The classifer would return the
> same kind of information as secmark, some user provided label that is
> delivered to the LSM policy side.

I think there is a misunderstanding in either how secmark works or how
the LSMs use secmark labels when enforcing their security policy.

The secmark label is set on a packet to represent the network
properties of a packet.  While the rules governing how a packet's
secmark is set and the semantic meaning of that secmark label is going
to be LSM and solution specific, secmark labels represent the
properties of a packet and not the operation, e.g.
send/receive/forward/etc., being requested at a given access control
point.  The access control point itself represents the requested
operation.  This is possible because the number of networking
operations on a given packet is well defined and fairly limited; at a
high level the packet is either being sent from the node, received by
the node, or is passing through the node.

As I understand the firmware controls being proposed here, encoded
within the firmware request blob is the operation being requested.
While we've discussed possible solutions on how to parse the request
blob to determine the operation, we haven't really discussed how to
represent the requested operation to the LSMs.  I'm assuming there
isn't a well defined set of operations, and like the request format
itself, the set of valid operations will vary from device and firmware
revision.  I hope you can understand both how this differs from
secmark and that it is a challenge that really hasn't been addressed
in the proposals we've discussed.

At a very high level the access control decision for firmware/device
requests depends on whether the LSM wants to allow process A to do B
to device C.  The identity/credentials associated with process A are
easy to understand, we have plenty of examples both inside and outside
of the LSM on how to do that.  The device identity/attributes
associated with device C can be a bit trickier, but once again we have
plenty of examples to draw from, and we can even fall back to a
generic "kernel" id/attribute if the LSM chooses not to distinguish
entities below the userspace/kernel boundary.  I think the hardest
issue with the firmware request hooks is going to be determining what
operation is being requested, the "B", portion of access request
tuple.  If we can create a well defined set of operations and leave it
to the parser to characterize the operation we've potentially got a
solution, but if the operation is truly going to be arbitrary then we
have a real problem.  How do you craft a meaningful access control
policy when you don't understand what is being requested?

-- 
paul-moore.com