Re: [PATCH rdma-next 23/23] RDMA/mlx5: Advertise adversarial mode via ib_device::adversarial_mode

[Yishai Hadas <yishaih@nvidia.com>]

On 07/11/2026 22:25, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 1 · Low: 1
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] The series is not bisectable on confidential-computing (CoCo)
>    guests.
> - [Low] The commit message understates what this one line does.
> 
> --
> 
> RDMA/mlx5: Advertise adversarial mode via ib_device::adversarial_mode
> 
> This commit sets ib_device::adversarial_mode from the
> mlx5_ib_adversarial_mode global in mlx5_ib_stage_caps_init(). The uverbs
> core can then report adversarial mode to rdma-core and only let
> adversarial-mode-aware userspace open a context on the device.
> 
>> diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
>> index ace4cdc95c9da..f8af90941b53d 100644
>> --- a/drivers/infiniband/hw/mlx5/main.c
>> +++ b/drivers/infiniband/hw/mlx5/main.c
>> @@ -4778,6 +4778,7 @@ static int mlx5_ib_stage_caps_init(struct mlx5_ib_dev *dev)
>>   	}
>>   
>>   	dev->ib_dev.use_cq_dim = true;
>> +	dev->ib_dev.adversarial_mode = mlx5_ib_adversarial_mode;
> 
> [Severity: Medium]
> Can the series still be bisected on CoCo guests when this assignment
> comes last?
> 
> An earlier patch, "RDMA/mlx5: Derive mlx5_ib_adversarial_mode global from
> mlx5_core adversarial API", sets the global in mlx5_ib_init():
> 
>      mlx5_ib_adversarial_mode = mlx5_is_adversarial();
> 
> This comes from cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT), so it is true
> on any SEV-SNP/TDX guest.
> 
> Next, "RDMA/mlx5: Block generic CQ poll path in adversarial mode" adds
> this to mlx5_poll_one():
> 
>      if (unlikely(mlx5_ib_adversarial_mode))
>          return -EOPNOTSUPP;
> 
> That patch says this is safe because kernel ULPs don't bind to the device.
> 
> However, kernel ULPs only stop binding once ib_device_check_mandatory()
> sees the core flag:
> 
>      if (device->adversarial_mode)
>          device->kverbs_provider = false;
> 
> mlx5 doesn't set ib_dev.adversarial_mode until this commit.
> 
> That leaves a window from the CQ poll blocking patch up to "RDMA/core:
> Report and enforce adversarial mode via GET_CONTEXT". In that window,
> kverbs_provider stays true for mlx5 on a CoCo guest.
> 
> add_client_context() then binds MAD, CM, rdma_cm, IPoIB, SRP, iSER,
> NVMe-oF and the other clients. Their CQs use mlx5_poll_one():
> 
> mlx5_ib_poll_cq()
>    cq->poll_one() == mlx5_poll_one()
>      returns -EOPNOTSUPP
> 
> mlx5_ib_poll_cq() stops at the first non-zero return, so it always reports
> 0 completions. Wouldn't MAD sends time out, the IPoIB TX ring fill up, and
> NVMe-oF/SRP I/O hang in those intermediate commits?
> 
> In the same window, legacy rdma-core would still get contexts, and uverbs
> POLL_CQ would always come back empty.
> 
> Could this assignment move into the patch that enables the driver-side
> mode? Another option is to place it right after "RDMA/core: Suppress
> kverbs_provider for adversarial_mode devices", before any hardening patch
> that changes behaviour. Either way, every commit in the series would keep
> working.

Setting ib_dev.adversarial_mode declares that the device supports 
adversarial mode, so it is done last, once all the hardening is in
place. Adversarial mode is not expected to be used with only part of the 
series.

> 
> [Severity: Low]
> This isn't a bug, but the commit message only says:
> 
>      Set ib_device::adversarial_mode during capability init so that the
>      uverbs core layer can report adversarial mode to rdma-core and enforce
>      that only adversarial-mode-aware userspace opens a context on this
>      device.
> 
> In practice, this line turns on the full adversarial policy for every
> mlx5 ib_device on a CC_ATTR_GUEST_MEM_ENCRYPT guest. The pf, raw_eth/rep
> and plane profiles all run MLX5_IB_STAGE_CAPS.
> 
> With the flag set, ib_device_check_mandatory() clears kverbs_provider.
> add_client_context() then skips every client that lacks no_kverbs_req:
> 
>      if (!device->kverbs_provider && !client->no_kverbs_req)
>          return 0;
> 
> Only uverbs has no_kverbs_req. As a result, MAD, ib_umad, IB CM, SA,
> rdma_cm, IPoIB, SRP, iSER, NVMe-oF, NFS/RDMA, RDS and SMC-R no longer
> bind.
> 
> Because cma and SA never bind, librdmacm users going through ucma can't
> use the device either, even if they are adversarial-aware.
> 
> Unmodified rdma-core also gets -EPERM, both from GET_CONTEXT and from the
> legacy write() path.
> 
> There is no opt-out, since the decision comes only from
> cc_platform_has(). Other patches in the series say this is intended, but
> this commit is where it takes effect for mlx5.
> 
> Could the commit message say that, once this is applied, kernel ULPs and
> rdma_cm-based userspace stop working on mlx5 in CoCo guests?
> 
>>   
>>   	return 0;
>>
> 

OK, will update the commit message in V1.

Yishai