mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-08-05 16:54:27 +00:00
52929c2142
mlx5 FW has a built in security context called UID. Each UID has a set of permissions controlled by the kernel when it is created and every command is tagged by the kernel with a particular UID. In general commands cannot reach objects outside of their UID and commands cannot exceed their UID's permissions. These restrictions are enforced by FW. This mechanism has long been used in RDMA for the devx interface where RDMA will sent commands directly to the FW and the UID limitations restrict those commands to a ib_device/verbs security domain. For instance commands that would effect other VFs, or global device resources. The model is suitable for unprivileged userspace to operate the RDMA functionality. The UID has been extended with a "tools resources" permission which allows additional commands and sub-commands that are intended to match with the scope limitations set in FWCTL. This is an alternative design to the "command intent log" where the FW does the enforcement rather than having the FW report the enforcement the kernel should do. Consistent with the fwctl definitions the "tools resources" security context is limited to the FWCTL_RPC_CONFIGURATION, FWCTL_RPC_DEBUG_READ_ONLY, FWCTL_RPC_DEBUG_WRITE, and FWCTL_RPC_DEBUG_WRITE_FULL security scopes. Like RDMA devx, each opened fwctl file descriptor will get a unique UID associated with each file descriptor. The fwctl driver is kept simple and we reject commands that can create objects as the UID mechanism relies on the kernel to track and destroy objects prior to detroying the UID. Filtering into fwctl sub scopes is done inside the driver with a switch statement. This substantially limits what is possible to primarily query functions ad a few limited set operations. mlx5 already has a robust infrastructure for delivering RPC messages to fw. Trivially connect fwctl's RPC mechanism to mlx5_cmd_do(). Enforce the User Context ID in every RPC header accepted from the FD so the FW knows the security context of the issuing ID. Link: https://patch.msgid.link/r/7-v5-642aa0c94070+4447f-fwctl_jgg@nvidia.com Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
36 lines
1.2 KiB
C
36 lines
1.2 KiB
C
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
|
|
/*
|
|
* Copyright (c) 2024-2025, NVIDIA CORPORATION & AFFILIATES
|
|
*
|
|
* These are definitions for the command interface for mlx5 HW. mlx5 FW has a
|
|
* User Context mechanism which allows the FW to understand a security scope.
|
|
* FWCTL binds each FD to a FW user context and then places the User Context ID
|
|
* (UID) in each command header. The created User Context has a capability set
|
|
* that is appropriate for FWCTL's security model.
|
|
*
|
|
* Command formation should use a copy of the structs in mlx5_ifc.h following
|
|
* the Programmers Reference Manual. A open release is available here:
|
|
*
|
|
* https://network.nvidia.com/files/doc-2020/ethernet-adapters-programming-manual.pdf
|
|
*
|
|
* The device_type for this file is FWCTL_DEVICE_TYPE_MLX5.
|
|
*/
|
|
#ifndef _UAPI_FWCTL_MLX5_H
|
|
#define _UAPI_FWCTL_MLX5_H
|
|
|
|
#include <linux/types.h>
|
|
|
|
/**
|
|
* struct fwctl_info_mlx5 - ioctl(FWCTL_INFO) out_device_data
|
|
* @uid: The FW UID this FD is bound to. Each command header will force
|
|
* this value.
|
|
* @uctx_caps: The FW capabilities that are enabled for the uid.
|
|
*
|
|
* Return basic information about the FW interface available.
|
|
*/
|
|
struct fwctl_info_mlx5 {
|
|
__u32 uid;
|
|
__u32 uctx_caps;
|
|
};
|
|
|
|
#endif
|