Re: [PATCH rdma-next 08/23] RDMA/core: Suppress kverbs_provider for adversarial_mode devices

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] At this commit, nothing in the tree writes the new struct
  ib_device::adversarial_mode field.
- [Low] Clearing kverbs_provider in ib_device_check_mandatory() for
  adversarial_mode devices does more than keep in-kernel ULPs off the…

--

RDMA/core: Suppress kverbs_provider for adversarial_mode devices

This commit adds an adversarial_mode field to struct ib_device. When the
field is set, ib_device_check_mandatory() clears kverbs_provider. After
that, add_client_context() only lets clients with no_kverbs_req (uverbs)
bind to the device, which keeps kernel ULPs off an untrusted NIC.

> diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
> index 29af9fe860e27..eb6aa567d3652 100644
> --- a/drivers/infiniband/core/device.c
> +++ b/drivers/infiniband/core/device.c
> @@ -312,6 +312,14 @@ static void ib_device_check_mandatory(struct ib_device *device)
>  			break;
>  		}
>  	}
> +
> +	/*
> +	 * Kernel ULPs must not bind to an adversarial_mode device. Its kverbs
> +	 * ops are still present, as uverbs uses them, so clear kverbs_provider
> +	 * explicitly. uverbs sets no_kverbs_req, so it still binds.
> +	 */
> +	if (device->adversarial_mode)
> +		device->kverbs_provider = false;

[Severity: Low]
At this commit, does anything set ib_device->adversarial_mode?

mlx5 has its own module-global flag, set in mlx5_ib_init(), but this
commit does not copy it into the ib_device:

drivers/infiniband/hw/mlx5/main.c:
bool mlx5_ib_adversarial_mode;
...
	mlx5_ib_adversarial_mode = mlx5_is_adversarial();

So the field stays zero, this check never fires, and add_client_context()
still binds every kernel client. The commit message says "the kernel ULPs
never bind to the device", which is not true for this commit on its own.

The last patch in the series, "RDMA/mlx5: Advertise adversarial mode via
ib_device::adversarial_mode", adds this line to mlx5_ib_stage_caps_init():

	dev->ib_dev.adversarial_mode = mlx5_ib_adversarial_mode;

MLX5_IB_STAGE_CAPS runs before MLX5_IB_STAGE_IB_REG in all mlx5 profiles,
so the gate works once the whole series is applied.

The remaining problem is bisectability. Between "RDMA/mlx5: Block generic
CQ poll path in adversarial mode" and that final patch, kernel ULPs can
still bind in a CoCo guest while mlx5_poll_one() returns -EOPNOTSUPP. In
that window mlx5_ib_poll_cq() reports zero completions to every ULP CQ.

Could the patch that sets ib_dev.adversarial_mode be moved before the one
that blocks the CQ poll path?

[Severity: Low]
This also keeps umad and cma from binding, not just the in-kernel ULPs.
Only uverbs sets no_kverbs_req:

drivers/infiniband/core/uverbs_main.c:
	.no_kverbs_req = true,

so add_client_context() returns early for every other client:

	if (!device->kverbs_provider && !client->no_kverbs_req)
		return 0;

Without umad, no /dev/infiniband/umadN nodes are created for the device.

Without cma, the device never joins cma's device list, so ucma and
librdmacm cannot bind or resolve on it.

This looks intended, since the kernel MAD and CM layers interpret
device-supplied data. Should the commit message say that userspace MAD
and rdma_cm are not available on an adversarial_mode device?

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261103163949.1554-1-yishaih%40nvidia.com