[PATCH 0/3] Firmware LSM hook

[PATCH 0/3] Firmware LSM hook

[Leon Romanovsky]

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.

Thanks

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
Chiara Meiohas (3):
      lsm: add hook for firmware command validation
      RDMA/mlx5: Invoke fw_validate_cmd LSM hook for DEVX commands
      fwctl/mlx5: Invoke fw_validate_cmd LSM hook for fwctl commands

 drivers/fwctl/mlx5/main.c         | 12 +++++++--
 drivers/infiniband/hw/mlx5/devx.c | 52 ++++++++++++++++++++++++++++++---------
 include/linux/lsm_hook_defs.h     |  2 ++
 include/linux/security.h          | 25 +++++++++++++++++++
 security/security.c               | 26 ++++++++++++++++++++
 5 files changed, 103 insertions(+), 14 deletions(-)
---
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
change-id: 20260309-fw-lsm-hook-7c094f909ffc

Best regards,
--  
Leon Romanovsky <leonro@nvidia.com>

[PATCH 1/3] lsm: add hook for firmware command validation

[Leon Romanovsky]

From: Chiara Meiohas <cmeiohas@nvidia.com>

Drivers typically communicate with device firmware either via
register-based commands (writing parameters into device registers)
or by passing a command buffer using shared-memory mechanisms.

This hook targets the command buffer mechanism, which is commonly
used on modern, complex devices.

Add the LSM hook fw_validate_cmd. This hook allows inspecting
firmware command buffers before they are sent to the device.
The hook receives the command buffer, device, command class, and a
class-specific id:
  - class_id (enum fw_cmd_class) allows security modules to
    differentiate between classes of firmware commands.
    In this series, class_id distinguishes between commands from the
    RDMA uverbs interface and from fwctl.
  - id is a class-specific device identifier. For uverbs, id is the
    RDMA driver identifier (enum rdma_driver_id). For fwctl, id is the
    device type (enum fwctl_device_type).

Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 include/linux/lsm_hook_defs.h |  2 ++
 include/linux/security.h      | 25 +++++++++++++++++++++++++
 security/security.c           | 26 ++++++++++++++++++++++++++
 3 files changed, 53 insertions(+)

diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 8c42b4bde09c0..93da090384ea1 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -445,6 +445,8 @@ LSM_HOOK(int, 0, bpf_token_capable, const struct bpf_token *token, int cap)
 #endif /* CONFIG_BPF_SYSCALL */
 
 LSM_HOOK(int, 0, locked_down, enum lockdown_reason what)
+LSM_HOOK(int, 0, fw_validate_cmd, const void *in, size_t in_len,
+	 const struct device *dev, enum fw_cmd_class class_id, u32 id)
 
 #ifdef CONFIG_PERF_EVENTS
 LSM_HOOK(int, 0, perf_event_open, int type)
diff --git a/include/linux/security.h b/include/linux/security.h
index 83a646d72f6f8..64786d013207a 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -67,6 +67,7 @@ enum fs_value_type;
 struct watch;
 struct watch_notification;
 struct lsm_ctx;
+struct device;
 
 /* Default (no) options for the capable function */
 #define CAP_OPT_NONE 0x0
@@ -157,6 +158,21 @@ enum lockdown_reason {
 	LOCKDOWN_CONFIDENTIALITY_MAX,
 };
 
+/*
+ * enum fw_cmd_class - Class of the firmware command passed to
+ * security_fw_validate_cmd.
+ * This allows security modules to distinguish between different command
+ * classes.
+ *
+ * @FW_CMD_CLASS_UVERBS: Command originated from the RDMA uverbs interface
+ * @FW_CMD_CLASS_FWCTL: Command originated from the fwctl interface
+ */
+enum fw_cmd_class {
+	FW_CMD_CLASS_UVERBS,
+	FW_CMD_CLASS_FWCTL,
+	FW_CMD_CLASS_MAX,
+};
+
 /*
  * Data exported by the security modules
  */
@@ -575,6 +591,9 @@ int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
 int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
 int security_inode_getsecctx(struct inode *inode, struct lsm_context *cp);
 int security_locked_down(enum lockdown_reason what);
+int security_fw_validate_cmd(const void *in, size_t in_len,
+			     const struct device *dev,
+			     enum fw_cmd_class class_id, u32 id);
 int lsm_fill_user_ctx(struct lsm_ctx __user *uctx, u32 *uctx_len,
 		      void *val, size_t val_len, u64 id, u64 flags);
 int security_bdev_alloc(struct block_device *bdev);
@@ -1589,6 +1608,12 @@ static inline int security_locked_down(enum lockdown_reason what)
 {
 	return 0;
 }
+static inline int security_fw_validate_cmd(const void *in, size_t in_len,
+					   const struct device *dev,
+					   enum fw_cmd_class class_id, u32 id)
+{
+	return 0;
+}
 static inline int lsm_fill_user_ctx(struct lsm_ctx __user *uctx,
 				    u32 *uctx_len, void *val, size_t val_len,
 				    u64 id, u64 flags)
diff --git a/security/security.c b/security/security.c
index 67af9228c4e94..d05941fe89a48 100644
--- a/security/security.c
+++ b/security/security.c
@@ -5373,6 +5373,32 @@ int security_locked_down(enum lockdown_reason what)
 }
 EXPORT_SYMBOL(security_locked_down);
 
+/**
+ * security_fw_validate_cmd() - Validate a firmware command
+ * @in: pointer to the firmware command input buffer
+ * @in_len: length of the firmware command input buffer
+ * @dev: device associated with the command
+ * @class_id: class of the firmware command
+ * @id: device identifier, specific to the command @class_id
+ *
+ * Check permissions before sending a firmware command generated by
+ * userspace to the device.
+ *
+ * Return: Returns 0 if permission is granted.
+ */
+int security_fw_validate_cmd(const void *in, size_t in_len,
+			     const struct device *dev,
+			     enum fw_cmd_class class_id,
+			     u32 id)
+{
+	if (class_id >= FW_CMD_CLASS_MAX)
+		return -EINVAL;
+
+	return call_int_hook(fw_validate_cmd, in, in_len,
+			     dev, class_id, id);
+}
+EXPORT_SYMBOL_GPL(security_fw_validate_cmd);
+
 /**
  * security_bdev_alloc() - Allocate a block device LSM blob
  * @bdev: block device

-- 
2.53.0

Re: [PATCH 1/3] lsm: add hook for firmware command validation

[Jonathan Cameron]

On Mon,  9 Mar 2026 13:15:18 +0200
Leon Romanovsky <leon@kernel.org> wrote:

> From: Chiara Meiohas <cmeiohas@nvidia.com>
> 
> Drivers typically communicate with device firmware either via
> register-based commands (writing parameters into device registers)
> or by passing a command buffer using shared-memory mechanisms.
> 
> This hook targets the command buffer mechanism, which is commonly
> used on modern, complex devices.
> 
> Add the LSM hook fw_validate_cmd. This hook allows inspecting
> firmware command buffers before they are sent to the device.
> The hook receives the command buffer, device, command class, and a
> class-specific id:
>   - class_id (enum fw_cmd_class) allows security modules to
>     differentiate between classes of firmware commands.
>     In this series, class_id distinguishes between commands from the
>     RDMA uverbs interface and from fwctl.
>   - id is a class-specific device identifier. For uverbs, id is the
>     RDMA driver identifier (enum rdma_driver_id). For fwctl, id is the
>     device type (enum fwctl_device_type).
> 
> Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
> Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
> Signed-off-by: Edward Srouji <edwards@nvidia.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Hi Leon,

To me this seems sensible, but LSM isn't an area I know that much about.

With that in mind:
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>

A few formatting related comments inline.

> diff --git a/include/linux/security.h b/include/linux/security.h
> index 83a646d72f6f8..64786d013207a 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -67,6 +67,7 @@ enum fs_value_type;
>  struct watch;
>  struct watch_notification;
>  struct lsm_ctx;
> +struct device;
>  
>  /* Default (no) options for the capable function */
>  #define CAP_OPT_NONE 0x0
> @@ -157,6 +158,21 @@ enum lockdown_reason {
>  	LOCKDOWN_CONFIDENTIALITY_MAX,
>  };
>  
> +/*
Could add the MAX entry and making this /**
The file is a bit inconsistent on that.

> + * enum fw_cmd_class - Class of the firmware command passed to
> + * security_fw_validate_cmd.
> + * This allows security modules to distinguish between different command
> + * classes.
> + *
> + * @FW_CMD_CLASS_UVERBS: Command originated from the RDMA uverbs interface
> + * @FW_CMD_CLASS_FWCTL: Command originated from the fwctl interface
> + */
> +enum fw_cmd_class {
> +	FW_CMD_CLASS_UVERBS,
> +	FW_CMD_CLASS_FWCTL,
> +	FW_CMD_CLASS_MAX,
Nitpick. Drop the trailing comma to make it a tiny bit more obvious if
someone accidentally adds anything after this counting entry.

> +};
> +
>  /*
>   * Data exported by the security modules
>   */
> @@ -575,6 +591,9 @@ int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
>  int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
>  int security_inode_getsecctx(struct inode *inode, struct lsm_context *cp);
>  int security_locked_down(enum lockdown_reason what);
> +int security_fw_validate_cmd(const void *in, size_t in_len,
> +			     const struct device *dev,
> +			     enum fw_cmd_class class_id, u32 id);
>  int lsm_fill_user_ctx(struct lsm_ctx __user *uctx, u32 *uctx_len,
>  		      void *val, size_t val_len, u64 id, u64 flags);
>  int security_bdev_alloc(struct block_device *bdev);
> @@ -1589,6 +1608,12 @@ static inline int security_locked_down(enum lockdown_reason what)
>  {
>  	return 0;
>  }
> +static inline int security_fw_validate_cmd(const void *in, size_t in_len,
> +					   const struct device *dev,
> +					   enum fw_cmd_class class_id, u32 id)
> +{
> +	return 0;
> +}
>  static inline int lsm_fill_user_ctx(struct lsm_ctx __user *uctx,
>  				    u32 *uctx_len, void *val, size_t val_len,
>  				    u64 id, u64 flags)
> diff --git a/security/security.c b/security/security.c
> index 67af9228c4e94..d05941fe89a48 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -5373,6 +5373,32 @@ int security_locked_down(enum lockdown_reason what)
>  }
>  EXPORT_SYMBOL(security_locked_down);
>  
> +/**
> + * security_fw_validate_cmd() - Validate a firmware command
> + * @in: pointer to the firmware command input buffer
> + * @in_len: length of the firmware command input buffer
> + * @dev: device associated with the command
> + * @class_id: class of the firmware command
> + * @id: device identifier, specific to the command @class_id
> + *
> + * Check permissions before sending a firmware command generated by
> + * userspace to the device.
> + *
> + * Return: Returns 0 if permission is granted.
> + */
> +int security_fw_validate_cmd(const void *in, size_t in_len,
> +			     const struct device *dev,
> +			     enum fw_cmd_class class_id,
> +			     u32 id)

I'd follow the wrapping you have in the header and have id on the line
above.

> +{
> +	if (class_id >= FW_CMD_CLASS_MAX)
> +		return -EINVAL;
> +
> +	return call_int_hook(fw_validate_cmd, in, in_len,
> +			     dev, class_id, id);

Fits on one line < 80 chars.

> +}
> +EXPORT_SYMBOL_GPL(security_fw_validate_cmd);
> +
>  /**
>   * security_bdev_alloc() - Allocate a block device LSM blob
>   * @bdev: block device
> 

Re: [PATCH 1/3] lsm: add hook for firmware command validation

[Leon Romanovsky]

On Mon, Mar 09, 2026 at 03:02:53PM +0000, Jonathan Cameron wrote:
> On Mon,  9 Mar 2026 13:15:18 +0200
> Leon Romanovsky <leon@kernel.org> wrote:
> 
> > From: Chiara Meiohas <cmeiohas@nvidia.com>
> > 
> > Drivers typically communicate with device firmware either via
> > register-based commands (writing parameters into device registers)
> > or by passing a command buffer using shared-memory mechanisms.
> > 
> > This hook targets the command buffer mechanism, which is commonly
> > used on modern, complex devices.
> > 
> > Add the LSM hook fw_validate_cmd. This hook allows inspecting
> > firmware command buffers before they are sent to the device.
> > The hook receives the command buffer, device, command class, and a
> > class-specific id:
> >   - class_id (enum fw_cmd_class) allows security modules to
> >     differentiate between classes of firmware commands.
> >     In this series, class_id distinguishes between commands from the
> >     RDMA uverbs interface and from fwctl.
> >   - id is a class-specific device identifier. For uverbs, id is the
> >     RDMA driver identifier (enum rdma_driver_id). For fwctl, id is the
> >     device type (enum fwctl_device_type).
> > 
> > Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
> > Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
> > Signed-off-by: Edward Srouji <edwards@nvidia.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> Hi Leon,
> 
> To me this seems sensible, but LSM isn't an area I know that much about.
> 
> With that in mind:
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> 
> A few formatting related comments inline.

Thanks for the feedback. I’ve addressed all comments and will send a new
revision within the next few days.

Thanks

Re: [PATCH 1/3] lsm: add hook for firmware command validation

[Dave Jiang]

On 3/9/26 4:15 AM, Leon Romanovsky wrote:
> From: Chiara Meiohas <cmeiohas@nvidia.com>
> 
> Drivers typically communicate with device firmware either via
> register-based commands (writing parameters into device registers)
> or by passing a command buffer using shared-memory mechanisms.
> 
> This hook targets the command buffer mechanism, which is commonly
> used on modern, complex devices.
> 
> Add the LSM hook fw_validate_cmd. This hook allows inspecting
> firmware command buffers before they are sent to the device.
> The hook receives the command buffer, device, command class, and a
> class-specific id:
>   - class_id (enum fw_cmd_class) allows security modules to
>     differentiate between classes of firmware commands.
>     In this series, class_id distinguishes between commands from the
>     RDMA uverbs interface and from fwctl.
>   - id is a class-specific device identifier. For uverbs, id is the
>     RDMA driver identifier (enum rdma_driver_id). For fwctl, id is the
>     device type (enum fwctl_device_type).
> 
> Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
> Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
> Signed-off-by: Edward Srouji <edwards@nvidia.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>

Reviewed-by: Dave Jiang <dave.jiang@intel.com>

> ---
>  include/linux/lsm_hook_defs.h |  2 ++
>  include/linux/security.h      | 25 +++++++++++++++++++++++++
>  security/security.c           | 26 ++++++++++++++++++++++++++
>  3 files changed, 53 insertions(+)
> 
> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> index 8c42b4bde09c0..93da090384ea1 100644
> --- a/include/linux/lsm_hook_defs.h
> +++ b/include/linux/lsm_hook_defs.h
> @@ -445,6 +445,8 @@ LSM_HOOK(int, 0, bpf_token_capable, const struct bpf_token *token, int cap)
>  #endif /* CONFIG_BPF_SYSCALL */
>  
>  LSM_HOOK(int, 0, locked_down, enum lockdown_reason what)
> +LSM_HOOK(int, 0, fw_validate_cmd, const void *in, size_t in_len,
> +	 const struct device *dev, enum fw_cmd_class class_id, u32 id)
>  
>  #ifdef CONFIG_PERF_EVENTS
>  LSM_HOOK(int, 0, perf_event_open, int type)
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 83a646d72f6f8..64786d013207a 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -67,6 +67,7 @@ enum fs_value_type;
>  struct watch;
>  struct watch_notification;
>  struct lsm_ctx;
> +struct device;
>  
>  /* Default (no) options for the capable function */
>  #define CAP_OPT_NONE 0x0
> @@ -157,6 +158,21 @@ enum lockdown_reason {
>  	LOCKDOWN_CONFIDENTIALITY_MAX,
>  };
>  
> +/*
> + * enum fw_cmd_class - Class of the firmware command passed to
> + * security_fw_validate_cmd.
> + * This allows security modules to distinguish between different command
> + * classes.
> + *
> + * @FW_CMD_CLASS_UVERBS: Command originated from the RDMA uverbs interface
> + * @FW_CMD_CLASS_FWCTL: Command originated from the fwctl interface
> + */
> +enum fw_cmd_class {
> +	FW_CMD_CLASS_UVERBS,
> +	FW_CMD_CLASS_FWCTL,
> +	FW_CMD_CLASS_MAX,
> +};
> +
>  /*
>   * Data exported by the security modules
>   */
> @@ -575,6 +591,9 @@ int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
>  int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
>  int security_inode_getsecctx(struct inode *inode, struct lsm_context *cp);
>  int security_locked_down(enum lockdown_reason what);
> +int security_fw_validate_cmd(const void *in, size_t in_len,
> +			     const struct device *dev,
> +			     enum fw_cmd_class class_id, u32 id);
>  int lsm_fill_user_ctx(struct lsm_ctx __user *uctx, u32 *uctx_len,
>  		      void *val, size_t val_len, u64 id, u64 flags);
>  int security_bdev_alloc(struct block_device *bdev);
> @@ -1589,6 +1608,12 @@ static inline int security_locked_down(enum lockdown_reason what)
>  {
>  	return 0;
>  }
> +static inline int security_fw_validate_cmd(const void *in, size_t in_len,
> +					   const struct device *dev,
> +					   enum fw_cmd_class class_id, u32 id)
> +{
> +	return 0;
> +}
>  static inline int lsm_fill_user_ctx(struct lsm_ctx __user *uctx,
>  				    u32 *uctx_len, void *val, size_t val_len,
>  				    u64 id, u64 flags)
> diff --git a/security/security.c b/security/security.c
> index 67af9228c4e94..d05941fe89a48 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -5373,6 +5373,32 @@ int security_locked_down(enum lockdown_reason what)
>  }
>  EXPORT_SYMBOL(security_locked_down);
>  
> +/**
> + * security_fw_validate_cmd() - Validate a firmware command
> + * @in: pointer to the firmware command input buffer
> + * @in_len: length of the firmware command input buffer
> + * @dev: device associated with the command
> + * @class_id: class of the firmware command
> + * @id: device identifier, specific to the command @class_id
> + *
> + * Check permissions before sending a firmware command generated by
> + * userspace to the device.
> + *
> + * Return: Returns 0 if permission is granted.
> + */
> +int security_fw_validate_cmd(const void *in, size_t in_len,
> +			     const struct device *dev,
> +			     enum fw_cmd_class class_id,
> +			     u32 id)
> +{
> +	if (class_id >= FW_CMD_CLASS_MAX)
> +		return -EINVAL;
> +
> +	return call_int_hook(fw_validate_cmd, in, in_len,
> +			     dev, class_id, id);
> +}
> +EXPORT_SYMBOL_GPL(security_fw_validate_cmd);
> +
>  /**
>   * security_bdev_alloc() - Allocate a block device LSM blob
>   * @bdev: block device
> 

[PATCH 2/3] RDMA/mlx5: Invoke fw_validate_cmd LSM hook for DEVX commands

[Leon Romanovsky]

From: Chiara Meiohas <cmeiohas@nvidia.com>

DEVX is an RDMA uverbs extension that allows userspace to submit
firmware command buffers. The driver inspects the command and then
passes the buffer through for firmware execution.

Call security_fw_validate_cmd() before dispatching firmware commands
through DEVX.

This allows security modules to implement custom policies and
enforce per-command security policy on user-triggered firmware
commands. For example, a BPF LSM program could restrict specific
firmware operations to privileged users.

Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 drivers/infiniband/hw/mlx5/devx.c | 52 ++++++++++++++++++++++++++++++---------
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c
index 0066b2738ac89..48a2c4b4ad4eb 100644
--- a/drivers/infiniband/hw/mlx5/devx.c
+++ b/drivers/infiniband/hw/mlx5/devx.c
@@ -18,6 +18,7 @@
 #include "devx.h"
 #include "qp.h"
 #include <linux/xarray.h>
+#include <linux/security.h>
 
 #define UVERBS_MODULE_NAME mlx5_ib
 #include <rdma/uverbs_named_ioctl.h>
@@ -1111,6 +1112,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OTHER)(
 	struct mlx5_ib_dev *dev;
 	void *cmd_in = uverbs_attr_get_alloced_ptr(
 		attrs, MLX5_IB_ATTR_DEVX_OTHER_CMD_IN);
+	int cmd_in_len = uverbs_attr_get_len(attrs,
+					MLX5_IB_ATTR_DEVX_OTHER_CMD_IN);
 	int cmd_out_len = uverbs_attr_get_len(attrs,
 					MLX5_IB_ATTR_DEVX_OTHER_CMD_OUT);
 	void *cmd_out;
@@ -1135,9 +1138,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OTHER)(
 		return PTR_ERR(cmd_out);
 
 	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
-	err = mlx5_cmd_do(dev->mdev, cmd_in,
-			  uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OTHER_CMD_IN),
-			  cmd_out, cmd_out_len);
+	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &dev->ib_dev.dev,
+				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
+	if (err)
+		return err;
+
+	err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out, cmd_out_len);
 	if (err && err != -EREMOTEIO)
 		return err;
 
@@ -1570,6 +1576,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
 		devx_set_umem_valid(cmd_in);
 	}
 
+	err = security_fw_validate_cmd(cmd_in, cmd_in_len,
+				       &dev->ib_dev.dev,
+				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
+	if (err)
+		goto obj_free;
+
 	if (opcode == MLX5_CMD_OP_CREATE_DCT) {
 		obj->flags |= DEVX_OBJ_FLAGS_DCT;
 		err = mlx5_core_create_dct(dev, &obj->core_dct, cmd_in,
@@ -1582,8 +1594,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
 				     cmd_in, cmd_in_len, cmd_out,
 				     cmd_out_len);
 	} else {
-		err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len,
-				  cmd_out, cmd_out_len);
+		err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out,
+				  cmd_out_len);
 	}
 
 	if (err == -EREMOTEIO)
@@ -1646,6 +1658,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_MODIFY)(
 	struct uverbs_attr_bundle *attrs)
 {
 	void *cmd_in = uverbs_attr_get_alloced_ptr(attrs, MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN);
+	int cmd_in_len = uverbs_attr_get_len(attrs,
+					MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN);
 	int cmd_out_len = uverbs_attr_get_len(attrs,
 					MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_OUT);
 	struct ib_uobject *uobj = uverbs_attr_get_uobject(attrs,
@@ -1676,9 +1690,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_MODIFY)(
 
 	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
 	devx_set_umem_valid(cmd_in);
+	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &mdev->ib_dev.dev,
+				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
+	if (err)
+		return err;
 
-	err = mlx5_cmd_do(mdev->mdev, cmd_in,
-			  uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN),
+	err = mlx5_cmd_do(mdev->mdev, cmd_in, cmd_in_len,
 			  cmd_out, cmd_out_len);
 	if (err && err != -EREMOTEIO)
 		return err;
@@ -1693,6 +1710,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_QUERY)(
 	struct uverbs_attr_bundle *attrs)
 {
 	void *cmd_in = uverbs_attr_get_alloced_ptr(attrs, MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_IN);
+	int cmd_in_len = uverbs_attr_get_len(attrs,
+					     MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_IN);
 	int cmd_out_len = uverbs_attr_get_len(attrs,
 					      MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_OUT);
 	struct ib_uobject *uobj = uverbs_attr_get_uobject(attrs,
@@ -1722,8 +1741,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_QUERY)(
 		return PTR_ERR(cmd_out);
 
 	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
-	err = mlx5_cmd_do(mdev->mdev, cmd_in,
-			  uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_IN),
+	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &mdev->ib_dev.dev,
+				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
+	if (err)
+		return err;
+
+	err = mlx5_cmd_do(mdev->mdev, cmd_in, cmd_in_len,
 			  cmd_out, cmd_out_len);
 	if (err && err != -EREMOTEIO)
 		return err;
@@ -1832,6 +1855,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_ASYNC_QUERY)(
 {
 	void *cmd_in = uverbs_attr_get_alloced_ptr(attrs,
 				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_CMD_IN);
+	int cmd_in_len = uverbs_attr_get_len(attrs,
+				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_CMD_IN);
 	struct ib_uobject *uobj = uverbs_attr_get_uobject(
 				attrs,
 				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_HANDLE);
@@ -1894,9 +1919,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_ASYNC_QUERY)(
 	async_data->ev_file = ev_file;
 
 	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
-	err = mlx5_cmd_exec_cb(&ev_file->async_ctx, cmd_in,
-		    uverbs_attr_get_len(attrs,
-				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_CMD_IN),
+	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &mdev->ib_dev.dev,
+				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
+	if (err)
+		goto free_async;
+
+	err = mlx5_cmd_exec_cb(&ev_file->async_ctx, cmd_in, cmd_in_len,
 		    async_data->hdr.out_data,
 		    async_data->cmd_out_len,
 		    devx_query_callback, &async_data->cb_work);

-- 
2.53.0

Re: [PATCH 2/3] RDMA/mlx5: Invoke fw_validate_cmd LSM hook for DEVX commands

[Jonathan Cameron]

On Mon,  9 Mar 2026 13:15:19 +0200
Leon Romanovsky <leon@kernel.org> wrote:

> From: Chiara Meiohas <cmeiohas@nvidia.com>
> 
> DEVX is an RDMA uverbs extension that allows userspace to submit
> firmware command buffers. The driver inspects the command and then
> passes the buffer through for firmware execution.
> 
> Call security_fw_validate_cmd() before dispatching firmware commands
> through DEVX.
> 
> This allows security modules to implement custom policies and
> enforce per-command security policy on user-triggered firmware
> commands. For example, a BPF LSM program could restrict specific
> firmware operations to privileged users.
> 
> Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
> Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
> Signed-off-by: Edward Srouji <edwards@nvidia.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
A few formatting inconsistencies.  Actual code is fine as far as I can tell.
So given I don't know the driver, take this as vague at best...

Assuming formatting stuff tidied up.

Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>


> ---
>  drivers/infiniband/hw/mlx5/devx.c | 52 ++++++++++++++++++++++++++++++---------
>  1 file changed, 40 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c
> index 0066b2738ac89..48a2c4b4ad4eb 100644
> --- a/drivers/infiniband/hw/mlx5/devx.c
> +++ b/drivers/infiniband/hw/mlx5/devx.c
> @@ -18,6 +18,7 @@
>  #include "devx.h"
>  #include "qp.h"
>  #include <linux/xarray.h>
> +#include <linux/security.h>
>  
>  #define UVERBS_MODULE_NAME mlx5_ib
>  #include <rdma/uverbs_named_ioctl.h>
> @@ -1111,6 +1112,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OTHER)(
>  	struct mlx5_ib_dev *dev;
>  	void *cmd_in = uverbs_attr_get_alloced_ptr(
>  		attrs, MLX5_IB_ATTR_DEVX_OTHER_CMD_IN);
> +	int cmd_in_len = uverbs_attr_get_len(attrs,
> +					MLX5_IB_ATTR_DEVX_OTHER_CMD_IN);
>  	int cmd_out_len = uverbs_attr_get_len(attrs,
>  					MLX5_IB_ATTR_DEVX_OTHER_CMD_OUT);
>  	void *cmd_out;
> @@ -1135,9 +1138,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OTHER)(
>  		return PTR_ERR(cmd_out);
>  
>  	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
> -	err = mlx5_cmd_do(dev->mdev, cmd_in,
> -			  uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OTHER_CMD_IN),
> -			  cmd_out, cmd_out_len);
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &dev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		return err;
> +
> +	err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out, cmd_out_len);

See below for inconsistency on how the changes have been done.

>  	if (err && err != -EREMOTEIO)
>  		return err;
>  
> @@ -1570,6 +1576,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
>  		devx_set_umem_valid(cmd_in);
>  	}
>  
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len,
> +				       &dev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		goto obj_free;
> +
>  	if (opcode == MLX5_CMD_OP_CREATE_DCT) {
>  		obj->flags |= DEVX_OBJ_FLAGS_DCT;
>  		err = mlx5_core_create_dct(dev, &obj->core_dct, cmd_in,
> @@ -1582,8 +1594,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
>  				     cmd_in, cmd_in_len, cmd_out,
>  				     cmd_out_len);
>  	} else {
> -		err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len,
> -				  cmd_out, cmd_out_len);
> +		err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out,
> +				  cmd_out_len);

Unrelated bit of reformatting. Shouldn't be in this patch.,


>  	}
>  
>  	if (err == -EREMOTEIO)
> @@ -1646,6 +1658,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_MODIFY)(
>  	struct uverbs_attr_bundle *attrs)
>  {
>  	void *cmd_in = uverbs_attr_get_alloced_ptr(attrs, MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN);
> +	int cmd_in_len = uverbs_attr_get_len(attrs,
> +					MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN);
>  	int cmd_out_len = uverbs_attr_get_len(attrs,
>  					MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_OUT);
>  	struct ib_uobject *uobj = uverbs_attr_get_uobject(attrs,
> @@ -1676,9 +1690,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_MODIFY)(
>  
>  	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
>  	devx_set_umem_valid(cmd_in);
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &mdev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		return err;
>  
> -	err = mlx5_cmd_do(mdev->mdev, cmd_in,
> -			  uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN),
> +	err = mlx5_cmd_do(mdev->mdev, cmd_in, cmd_in_len,
>  			  cmd_out, cmd_out_len);

Similar to case above, this not fits on one line.

>  	if (err && err != -EREMOTEIO)
>  		return err;
> @@ -1693,6 +1710,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_QUERY)(
>  	struct uverbs_attr_bundle *attrs)
>  {
>  	void *cmd_in = uverbs_attr_get_alloced_ptr(attrs, MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_IN);
> +	int cmd_in_len = uverbs_attr_get_len(attrs,
> +					     MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_IN);
>  	int cmd_out_len = uverbs_attr_get_len(attrs,
>  					      MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_OUT);
>  	struct ib_uobject *uobj = uverbs_attr_get_uobject(attrs,
> @@ -1722,8 +1741,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_QUERY)(
>  		return PTR_ERR(cmd_out);
>  
>  	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
> -	err = mlx5_cmd_do(mdev->mdev, cmd_in,
> -			  uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_IN),
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &mdev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		return err;
> +
> +	err = mlx5_cmd_do(mdev->mdev, cmd_in, cmd_in_len,
>  			  cmd_out, cmd_out_len);

As above.

>  	if (err && err != -EREMOTEIO)
>  		return err;
> @@ -1832,6 +1855,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_ASYNC_QUERY)(
>  {
>  	void *cmd_in = uverbs_attr_get_alloced_ptr(attrs,
>  				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_CMD_IN);
> +	int cmd_in_len = uverbs_attr_get_len(attrs,
> +				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_CMD_IN);
>  	struct ib_uobject *uobj = uverbs_attr_get_uobject(
>  				attrs,
>  				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_HANDLE);
> @@ -1894,9 +1919,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_ASYNC_QUERY)(
>  	async_data->ev_file = ev_file;
>  
>  	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
> -	err = mlx5_cmd_exec_cb(&ev_file->async_ctx, cmd_in,
> -		    uverbs_attr_get_len(attrs,
> -				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_CMD_IN),
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &mdev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		goto free_async;
> +
> +	err = mlx5_cmd_exec_cb(&ev_file->async_ctx, cmd_in, cmd_in_len,
>  		    async_data->hdr.out_data,
>  		    async_data->cmd_out_len,
>  		    devx_query_callback, &async_data->cb_work);
> 

Re: [PATCH 2/3] RDMA/mlx5: Invoke fw_validate_cmd LSM hook for DEVX commands

[Dave Jiang]

On 3/9/26 4:15 AM, Leon Romanovsky wrote:
> From: Chiara Meiohas <cmeiohas@nvidia.com>
> 
> DEVX is an RDMA uverbs extension that allows userspace to submit
> firmware command buffers. The driver inspects the command and then
> passes the buffer through for firmware execution.
> 
> Call security_fw_validate_cmd() before dispatching firmware commands
> through DEVX.
> 
> This allows security modules to implement custom policies and
> enforce per-command security policy on user-triggered firmware
> commands. For example, a BPF LSM program could restrict specific
> firmware operations to privileged users.
> 
> Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
> Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
> Signed-off-by: Edward Srouji <edwards@nvidia.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>

Reviewed-by: Dave Jiang <dave.jiang@intel.com>

> ---
>  drivers/infiniband/hw/mlx5/devx.c | 52 ++++++++++++++++++++++++++++++---------
>  1 file changed, 40 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c
> index 0066b2738ac89..48a2c4b4ad4eb 100644
> --- a/drivers/infiniband/hw/mlx5/devx.c
> +++ b/drivers/infiniband/hw/mlx5/devx.c
> @@ -18,6 +18,7 @@
>  #include "devx.h"
>  #include "qp.h"
>  #include <linux/xarray.h>
> +#include <linux/security.h>
>  
>  #define UVERBS_MODULE_NAME mlx5_ib
>  #include <rdma/uverbs_named_ioctl.h>
> @@ -1111,6 +1112,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OTHER)(
>  	struct mlx5_ib_dev *dev;
>  	void *cmd_in = uverbs_attr_get_alloced_ptr(
>  		attrs, MLX5_IB_ATTR_DEVX_OTHER_CMD_IN);
> +	int cmd_in_len = uverbs_attr_get_len(attrs,
> +					MLX5_IB_ATTR_DEVX_OTHER_CMD_IN);
>  	int cmd_out_len = uverbs_attr_get_len(attrs,
>  					MLX5_IB_ATTR_DEVX_OTHER_CMD_OUT);
>  	void *cmd_out;
> @@ -1135,9 +1138,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OTHER)(
>  		return PTR_ERR(cmd_out);
>  
>  	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
> -	err = mlx5_cmd_do(dev->mdev, cmd_in,
> -			  uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OTHER_CMD_IN),
> -			  cmd_out, cmd_out_len);
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &dev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		return err;
> +
> +	err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out, cmd_out_len);
>  	if (err && err != -EREMOTEIO)
>  		return err;
>  
> @@ -1570,6 +1576,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
>  		devx_set_umem_valid(cmd_in);
>  	}
>  
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len,
> +				       &dev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		goto obj_free;
> +
>  	if (opcode == MLX5_CMD_OP_CREATE_DCT) {
>  		obj->flags |= DEVX_OBJ_FLAGS_DCT;
>  		err = mlx5_core_create_dct(dev, &obj->core_dct, cmd_in,
> @@ -1582,8 +1594,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
>  				     cmd_in, cmd_in_len, cmd_out,
>  				     cmd_out_len);
>  	} else {
> -		err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len,
> -				  cmd_out, cmd_out_len);
> +		err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out,
> +				  cmd_out_len);
>  	}
>  
>  	if (err == -EREMOTEIO)
> @@ -1646,6 +1658,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_MODIFY)(
>  	struct uverbs_attr_bundle *attrs)
>  {
>  	void *cmd_in = uverbs_attr_get_alloced_ptr(attrs, MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN);
> +	int cmd_in_len = uverbs_attr_get_len(attrs,
> +					MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN);
>  	int cmd_out_len = uverbs_attr_get_len(attrs,
>  					MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_OUT);
>  	struct ib_uobject *uobj = uverbs_attr_get_uobject(attrs,
> @@ -1676,9 +1690,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_MODIFY)(
>  
>  	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
>  	devx_set_umem_valid(cmd_in);
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &mdev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		return err;
>  
> -	err = mlx5_cmd_do(mdev->mdev, cmd_in,
> -			  uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OBJ_MODIFY_CMD_IN),
> +	err = mlx5_cmd_do(mdev->mdev, cmd_in, cmd_in_len,
>  			  cmd_out, cmd_out_len);
>  	if (err && err != -EREMOTEIO)
>  		return err;
> @@ -1693,6 +1710,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_QUERY)(
>  	struct uverbs_attr_bundle *attrs)
>  {
>  	void *cmd_in = uverbs_attr_get_alloced_ptr(attrs, MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_IN);
> +	int cmd_in_len = uverbs_attr_get_len(attrs,
> +					     MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_IN);
>  	int cmd_out_len = uverbs_attr_get_len(attrs,
>  					      MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_OUT);
>  	struct ib_uobject *uobj = uverbs_attr_get_uobject(attrs,
> @@ -1722,8 +1741,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_QUERY)(
>  		return PTR_ERR(cmd_out);
>  
>  	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
> -	err = mlx5_cmd_do(mdev->mdev, cmd_in,
> -			  uverbs_attr_get_len(attrs, MLX5_IB_ATTR_DEVX_OBJ_QUERY_CMD_IN),
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &mdev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		return err;
> +
> +	err = mlx5_cmd_do(mdev->mdev, cmd_in, cmd_in_len,
>  			  cmd_out, cmd_out_len);
>  	if (err && err != -EREMOTEIO)
>  		return err;
> @@ -1832,6 +1855,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_ASYNC_QUERY)(
>  {
>  	void *cmd_in = uverbs_attr_get_alloced_ptr(attrs,
>  				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_CMD_IN);
> +	int cmd_in_len = uverbs_attr_get_len(attrs,
> +				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_CMD_IN);
>  	struct ib_uobject *uobj = uverbs_attr_get_uobject(
>  				attrs,
>  				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_HANDLE);
> @@ -1894,9 +1919,12 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_ASYNC_QUERY)(
>  	async_data->ev_file = ev_file;
>  
>  	MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
> -	err = mlx5_cmd_exec_cb(&ev_file->async_ctx, cmd_in,
> -		    uverbs_attr_get_len(attrs,
> -				MLX5_IB_ATTR_DEVX_OBJ_QUERY_ASYNC_CMD_IN),
> +	err = security_fw_validate_cmd(cmd_in, cmd_in_len, &mdev->ib_dev.dev,
> +				       FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> +	if (err)
> +		goto free_async;
> +
> +	err = mlx5_cmd_exec_cb(&ev_file->async_ctx, cmd_in, cmd_in_len,
>  		    async_data->hdr.out_data,
>  		    async_data->cmd_out_len,
>  		    devx_query_callback, &async_data->cb_work);
> 

[PATCH 3/3] fwctl/mlx5: Invoke fw_validate_cmd LSM hook for fwctl commands

[Leon Romanovsky]

From: Chiara Meiohas <cmeiohas@nvidia.com>

fwctl is subsystem which exposes a firmware interface directly to
userspace: it allows userspace to send device specific command
buffers to firmware.

Call security_fw_validate_cmd() before dispatching the user-provided
firmware command.

This allows security modules to implement custom policies and
enforce per-command security policy on user-triggered firmware
commands. For example, a BPF LSM program could filter firmware
commands based on their opcode.

Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 drivers/fwctl/mlx5/main.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/fwctl/mlx5/main.c b/drivers/fwctl/mlx5/main.c
index e86ab703c767a..8ed17aaf48f1f 100644
--- a/drivers/fwctl/mlx5/main.c
+++ b/drivers/fwctl/mlx5/main.c
@@ -7,6 +7,7 @@
 #include <linux/mlx5/device.h>
 #include <linux/mlx5/driver.h>
 #include <uapi/fwctl/mlx5.h>
+#include <linux/security.h>
 
 #define mlx5ctl_err(mcdev, format, ...) \
 	dev_err(&mcdev->fwctl.dev, format, ##__VA_ARGS__)
@@ -324,6 +325,15 @@ static void *mlx5ctl_fw_rpc(struct fwctl_uctx *uctx, enum fwctl_rpc_scope scope,
 	if (!mlx5ctl_validate_rpc(rpc_in, scope))
 		return ERR_PTR(-EBADMSG);
 
+	/* Enforce the user context for the command */
+	MLX5_SET(mbox_in_hdr, rpc_in, uid, mfd->uctx_uid);
+
+	ret = security_fw_validate_cmd(rpc_in, in_len, &mcdev->fwctl.dev,
+				       FW_CMD_CLASS_FWCTL,
+				       FWCTL_DEVICE_TYPE_MLX5);
+	if (ret)
+		return ERR_PTR(ret);
+
 	/*
 	 * mlx5_cmd_do() copies the input message to its own buffer before
 	 * executing it, so we can reuse the allocation for the output.
@@ -336,8 +346,6 @@ static void *mlx5ctl_fw_rpc(struct fwctl_uctx *uctx, enum fwctl_rpc_scope scope,
 			return ERR_PTR(-ENOMEM);
 	}
 
-	/* Enforce the user context for the command */
-	MLX5_SET(mbox_in_hdr, rpc_in, uid, mfd->uctx_uid);
 	ret = mlx5_cmd_do(mcdev->mdev, rpc_in, in_len, rpc_out, *out_len);
 
 	mlx5ctl_dbg(mcdev,

-- 
2.53.0

Re: [PATCH 3/3] fwctl/mlx5: Invoke fw_validate_cmd LSM hook for fwctl commands

[Jonathan Cameron]

On Mon,  9 Mar 2026 13:15:20 +0200
Leon Romanovsky <leon@kernel.org> wrote:

> From: Chiara Meiohas <cmeiohas@nvidia.com>
> 
> fwctl is subsystem which exposes a firmware interface directly to
> userspace: it allows userspace to send device specific command
> buffers to firmware.
> 
> Call security_fw_validate_cmd() before dispatching the user-provided
> firmware command.
> 
> This allows security modules to implement custom policies and
> enforce per-command security policy on user-triggered firmware
> commands. For example, a BPF LSM program could filter firmware
> commands based on their opcode.
> 
> Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
> Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
> Signed-off-by: Edward Srouji <edwards@nvidia.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
LGTM
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>

Re: [PATCH 3/3] fwctl/mlx5: Invoke fw_validate_cmd LSM hook for fwctl commands

[Dave Jiang]

On 3/9/26 4:15 AM, Leon Romanovsky wrote:
> From: Chiara Meiohas <cmeiohas@nvidia.com>
> 
> fwctl is subsystem which exposes a firmware interface directly to
> userspace: it allows userspace to send device specific command
> buffers to firmware.
> 
> Call security_fw_validate_cmd() before dispatching the user-provided
> firmware command.
> 
> This allows security modules to implement custom policies and
> enforce per-command security policy on user-triggered firmware
> commands. For example, a BPF LSM program could filter firmware
> commands based on their opcode.
> 
> Signed-off-by: Chiara Meiohas <cmeiohas@nvidia.com>
> Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
> Signed-off-by: Edward Srouji <edwards@nvidia.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>

Reviewed-by: Dave Jiang <dave.jiang@intel.com>

> ---
>  drivers/fwctl/mlx5/main.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fwctl/mlx5/main.c b/drivers/fwctl/mlx5/main.c
> index e86ab703c767a..8ed17aaf48f1f 100644
> --- a/drivers/fwctl/mlx5/main.c
> +++ b/drivers/fwctl/mlx5/main.c
> @@ -7,6 +7,7 @@
>  #include <linux/mlx5/device.h>
>  #include <linux/mlx5/driver.h>
>  #include <uapi/fwctl/mlx5.h>
> +#include <linux/security.h>
>  
>  #define mlx5ctl_err(mcdev, format, ...) \
>  	dev_err(&mcdev->fwctl.dev, format, ##__VA_ARGS__)
> @@ -324,6 +325,15 @@ static void *mlx5ctl_fw_rpc(struct fwctl_uctx *uctx, enum fwctl_rpc_scope scope,
>  	if (!mlx5ctl_validate_rpc(rpc_in, scope))
>  		return ERR_PTR(-EBADMSG);
>  
> +	/* Enforce the user context for the command */
> +	MLX5_SET(mbox_in_hdr, rpc_in, uid, mfd->uctx_uid);
> +
> +	ret = security_fw_validate_cmd(rpc_in, in_len, &mcdev->fwctl.dev,
> +				       FW_CMD_CLASS_FWCTL,
> +				       FWCTL_DEVICE_TYPE_MLX5);
> +	if (ret)
> +		return ERR_PTR(ret);
> +
>  	/*
>  	 * mlx5_cmd_do() copies the input message to its own buffer before
>  	 * executing it, so we can reuse the allocation for the output.
> @@ -336,8 +346,6 @@ static void *mlx5ctl_fw_rpc(struct fwctl_uctx *uctx, enum fwctl_rpc_scope scope,
>  			return ERR_PTR(-ENOMEM);
>  	}
>  
> -	/* Enforce the user context for the command */
> -	MLX5_SET(mbox_in_hdr, rpc_in, uid, mfd->uctx_uid);
>  	ret = mlx5_cmd_do(mcdev->mdev, rpc_in, in_len, rpc_out, *out_len);
>  
>  	mlx5ctl_dbg(mcdev,
> 

Re: [PATCH 0/3] Firmware LSM hook

[Paul Moore]

On Mon, Mar 9, 2026 at 7:15 AM Leon Romanovsky <leon@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

(If you lose the link, or simply for future reference, you can find it
in the "SECURITY SUBSYSTEM" MAINTAINERS entry.)

-- 
paul-moore.com

Re: [PATCH 0/3] Firmware LSM hook

[Leon Romanovsky]

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@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:
 * 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.

Here we propose a generic interface that can be applied to all FWCTL
devices without out-of-tree kernel code at all.

Thanks

> 
> (If you lose the link, or simply for future reference, you can find it
> in the "SECURITY SUBSYSTEM" MAINTAINERS entry.)
> 
> -- 
> paul-moore.com
> 

Re: [PATCH 0/3] Firmware LSM hook

[Paul Moore]

On Mon, Mar 9, 2026 at 3:37 PM Leon Romanovsky <leon@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@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

Re: [PATCH 0/3] Firmware LSM hook

[Leon Romanovsky]

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

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.

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

For example, at line 1140 we update the UID field, which indicates the
process to which the request belongs. This field is managed by the
kernel to ensure that user processes cannot access FW internals of other
processes.

1108 static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OTHER)( 
1109         struct uverbs_attr_bundle *attrs)            
1110 {                                                   
1111         struct mlx5_ib_ucontext *c;                
1112         struct mlx5_ib_dev *dev;                  
1113         void *cmd_in = uverbs_attr_get_alloced_ptr( 
1114                 attrs, MLX5_IB_ATTR_DEVX_OTHER_CMD_IN);

<...>

1121         int uid; 

<...>

1128         uid = devx_get_uid(c, cmd_in); 
1129         if (uid < 0)
1130                 return uid;                                                                                                                                                                              

<...>

1140         MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid); 
1141         err = security_fw_validate_cmd(cmd_in, cmd_in_len, &dev->ib_dev.dev, 
1142                                        FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
1143         if (err)
1144                 return err; 
1145                            
1146         err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out, cmd_out_len);      

Could you point me to the LSM that would be best suited for performing  
checks of this kind?

Thanks

> 
> --
> paul-moore.com

Re: [PATCH 0/3] Firmware LSM hook

[Stephen Smalley]

On Tue, Mar 10, 2026 at 5:14 AM Leon Romanovsky <leon@kernel.org> wrote:
> 1140         MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
> 1141         err = security_fw_validate_cmd(cmd_in, cmd_in_len, &dev->ib_dev.dev,
> 1142                                        FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> 1143         if (err)
> 1144                 return err;
> 1145
> 1146         err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out, cmd_out_len);
>
> Could you point me to the LSM that would be best suited for performing
> checks of this kind?

If you just want to filter on opcodes, then the SELinux extended
permissions (xperms) support may suffice, see:
https://blog.siphos.be/2017/11/selinux-and-extended-permissions/
https://kernsec.org/files/lss2015/vanderstoep.pdf
https://github.com/SELinuxProject/selinux-notebook/blob/main/src/xperm_rules.md

This was originally added to SELinux to support filtering ioctl
commands and later extended to netlink as well.

If you truly need/want filtering of arbitrary variable-length command
buffers, then I'm not sure any LSM does that today.
Might be best suited to Landlock but not sure even of that one.

Re: [PATCH 0/3] Firmware LSM hook

[Leon Romanovsky]

On Tue, Mar 10, 2026 at 12:29:40PM -0400, Stephen Smalley wrote:
> On Tue, Mar 10, 2026 at 5:14 AM Leon Romanovsky <leon@kernel.org> wrote:
> > 1140         MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
> > 1141         err = security_fw_validate_cmd(cmd_in, cmd_in_len, &dev->ib_dev.dev,
> > 1142                                        FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
> > 1143         if (err)
> > 1144                 return err;
> > 1145
> > 1146         err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out, cmd_out_len);
> >
> > Could you point me to the LSM that would be best suited for performing
> > checks of this kind?
> 
> If you just want to filter on opcodes, then the SELinux extended
> permissions (xperms) support may suffice, see:
> https://blog.siphos.be/2017/11/selinux-and-extended-permissions/
> https://kernsec.org/files/lss2015/vanderstoep.pdf
> https://github.com/SELinuxProject/selinux-notebook/blob/main/src/xperm_rules.md
> 
> This was originally added to SELinux to support filtering ioctl
> commands and later extended to netlink as well.
> 
> If you truly need/want filtering of arbitrary variable-length command
> buffers.

Yes. The opcode alone is not sufficient for any real‑world use.  
It is not reliable because different firmware versions place different  
parameters into the same mailbox entry under the same opcode.  
Without inspecting the mailbox contents, you cannot properly filter them.

Thanks

Re: [PATCH 0/3] Firmware LSM hook

[Paul Moore]

On Tue, Mar 10, 2026 at 5:07 AM Leon Romanovsky <leon@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@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@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.
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.  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
(this is somewhat similar to how the LSM framework doesn't necessarily
hook the syscalls, but the actions the syscalls perform).  Yes, one
does have to trust the firmware in this approach, but given the
relationship between the firmware and associated hardware, I think
users are implicitly required to trust their firmware in the vast
majority of cases.

-- 
paul-moore.com

Re: [PATCH 0/3] Firmware LSM hook

[Leon Romanovsky]

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

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

This is not a security‑sensitive operation that requires strict
restriction.

> (this is somewhat similar to how the LSM framework doesn't necessarily
> hook the syscalls, but the actions the syscalls perform).  Yes, one
> does have to trust the firmware in this approach, but given the
> relationship between the firmware and associated hardware, I think
> users are implicitly required to trust their firmware in the vast
> majority of cases.

They trust the firmware and the kernel, but they do not trust the actual  
non‑privileged users of that firmware.

Thanks

> 
> -- 
> paul-moore.com
> 

Re: [PATCH 0/3] Firmware LSM hook

[Paul Moore]

On Tue, Mar 10, 2026 at 3:30 PM Leon Romanovsky <leon@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@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@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@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

Re: [PATCH 0/3] Firmware LSM hook

[Leon Romanovsky]

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

Thanks

> 
> -- 
> paul-moore.com
> 

Re: [PATCH 0/3] Firmware LSM hook

[Paul Moore]

On Wed, Mar 11, 2026 at 4:20 AM Leon Romanovsky <leon@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@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@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@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@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.

-- 
paul-moore.com

Re: [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@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@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@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@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@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