Re: [PATCH v2 0/4] Firmware LSM hook

Re: [PATCH v2 0/4] Firmware LSM hook

[Paul Moore]

On Fri, Apr 24, 2026 at 6:13 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> ... I wonder if we are even speaking the same language.

Let's reset the conversation.

As I understand it, based on our discussion in this thread and Leon's
previous patchsets, the basic idea is to enable LSMs to enforce access
control over fwctl requests/commands sent from userspace.  I'm going
to start with that as a basis.

Using the kernel's docs on fwctl, the userspace API appears to consist
mostly of ioctls with some basic sysfs interfaces.  It looks like we
can mostly ignore the sysfs interface and focus on the ioctl side of
the API, do you agree?

https://docs.kernel.org/userspace-api/fwctl/fwctl.html

While normally I would suggest simply using the existing
security_file_ioctl() hook, Leon previously mentioned that the hook is
too early for fwctl as the userspace copy happens much later.  Looking
at the code, it appears that the copy happens in fwctl_fops_ioctl()
for all fwctl ioctls regardless of the device or ioctl, is that
correct?

Assuming the above is correct, how about the following LSM hook,
called after the copy_struct_from_user() in fwctl_fops_ioctl()?

 union fwctl_data {
   struct fwctl_info info;
   struct fwctl_rpc rpc;
 }

 int security_fwctl_ioctl(struct file *filep, unsigned int cmd, union
fwctl_data *arg)

Where @filep is the file/device being sent the ioctl, @cmd is the
ioctl command number (e.g. FWCTL_RPC), and @arg is the copied ioctl
data (e.g. ucmd.cmd in fwctl_fops_ioctl).  In addition to applying
access controls based on the ioctl command number, a capability that
already exists via the security_file_ioctl() hook, LSMs could also
apply access controls based on the RPC scope as well as any other well
defined data in the ioctl payload.

I expect most of the existing LSMs would implement callbacks for this
new hook with the subject being the process submitting the ioctl, the
object being the file/device that is being operated on with the
ioctl() call, and the access/privilege/verb/etc. being something along
the lines of INFO, RPC_CONFIG, RPC_DEBUG_READ, RPC_DEBUG_WRITE, or
RPC_DEBUG_WRITE_FULL.  Of course these are just quick examples to
demonstrate a point, please don't take those names as hard
requirements.  Each LSM is free to characterize the access request
however they like, in a way that best aligns with their security
model.

-- 
paul-moore.com

Re: [PATCH v2 0/4] Firmware LSM hook

[Leon Romanovsky]

On Mon, May 04, 2026 at 06:33:45PM -0400, Paul Moore wrote:
> On Fri, Apr 24, 2026 at 6:13 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > ... I wonder if we are even speaking the same language.
> 
> Let's reset the conversation.
> 
> As I understand it, based on our discussion in this thread and Leon's
> previous patchsets, the basic idea is to enable LSMs to enforce access
> control over fwctl requests/commands sent from userspace.  I'm going
> to start with that as a basis.

Yes, we proposed two users: FWCTL and RDMA DevX. Both are relevant, but
FWCTL is the higher priority.

> 
> Using the kernel's docs on fwctl, the userspace API appears to consist
> mostly of ioctls with some basic sysfs interfaces.  It looks like we
> can mostly ignore the sysfs interface and focus on the ioctl side of
> the API, do you agree?

Yes, all FW commands are routed through ioctls.

> 
> https://docs.kernel.org/userspace-api/fwctl/fwctl.html
> 
> While normally I would suggest simply using the existing
> security_file_ioctl() hook, Leon previously mentioned that the hook is
> too early for fwctl as the userspace copy happens much later.

I talked about general verbs interface in RDMA.

Thanks