Re: [PATCH rdma-next 07/15] RDMA/umem: Derive DMA direction from IB access flags

[Leon Romanovsky <leon@kernel.org>]

On Tue, Sep 08, 2026 at 06:28:43PM +0300, Yishai Hadas wrote:
> ib_umem_get_desc() / ib_umem_get_attr() / ib_umem_get_attr_or_va() can
> now derive the DMA direction from the IB access flags instead of always
> mapping DMA_BIDIRECTIONAL:
> 
>   - No write access granted (as determined by ib_access_writable():
>     IB_ACCESS_LOCAL_WRITE, IB_ACCESS_REMOTE_WRITE,
>     IB_ACCESS_REMOTE_ATOMIC, or IB_ACCESS_MW_BIND): the NIC may only
>     read the pages, so DMA_TO_DEVICE. This covers all callers that
>     pass access=0 (SRQ WQE rings, QP SQ/RQ WQE rings, doorbell
>     records) and MRs registered without write access
>     (IB_ACCESS_REMOTE_READ only).
> 
>   - Any such flag set: DMA_BIDIRECTIONAL, unchanged behaviour.
> 
> This is not just a theoretical default: it has been verified, driver by
> driver, against every QP SQ/RQ, SRQ, and doorbell-record buffer in the
> tree pinned this way -- mlx5, mlx4, bnxt_re, efa, ionic, qedr, mana,
> erdma, hns, and irdma all externalize their producer/consumer
> bookkeeping through a separate doorbell/UAR MMIO write or a distinct
> completion queue, never by the device writing back into the same buffer
> the CPU posts WQEs into. vmw_pvrdma is the sole exception, already
> pinning its QP/SRQ rings with IB_ACCESS_LOCAL_WRITE (see the earlier
> fix), so it continues to correctly derive DMA_BIDIRECTIONAL here without
> any special-casing.

Please read commit messages and remove the AI slop above. It is part of
claude/codex/... Intermediate prose which shouldn't be in the commit
message.

> 
> For dmabuf buffers the direction is managed by the dmabuf subsystem and
> ib_umem_get_desc() routes them unchanged, ignoring the derived
> direction. CQ buffers already get their own tighter, unconditional
> DMA_FROM_DEVICE mapping from the previous patch and are unaffected by
> this rule.

Same.

> 
> Security gain by platform:
>   - Platforms with a write-enforcing IOMMU (e.g. CoCo guests backed by
>     ARM SMMU or Intel VT-d in strict mode): a hostile device is
>     hardware-prevented from writing to read-only buffers (WQEs,
>     doorbell records), limiting corruption.
>   - Standard deployments without IOMMU direction enforcement: no
>     practical security effect today, but the correct semantic
>     declaration and zero runtime cost.
> 
> Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
> ---
>  drivers/infiniband/core/umem.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index f1da70c4e352..490ce660193e 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -329,7 +329,20 @@ struct ib_umem *ib_umem_get_desc(struct ib_device *device,
>  				 const struct ib_uverbs_buffer_desc *desc,
>  				 int access)
>  {
> -	return __ib_umem_get_desc_dir(device, desc, access, DMA_BIDIRECTIONAL);
> +	/*
> +	 * Derive the DMA direction from the IB access flags.  If the caller
> +	 * grants no write access (local or remote), the NIC may only read the
> +	 * pages - use DMA_TO_DEVICE so that platforms with a write-enforcing
> +	 * IOMMU (e.g. CoCo / SMMU with SMMU_CB_ARC_FAULT_ENABLE) can enforce
> +	 * the restriction.
> +	 *
> +	 * Where the IOMMU does not enforce direction (most x86 bare-metal
> +	 * deployments today) this has no security effect, but is still the
> +	 * correct semantic declaration and costs nothing.
> +	 */

Please remove these useless comments.

> +	return __ib_umem_get_desc_dir(device, desc, access,
> +				      ib_access_writable(access) ?
> +				      DMA_BIDIRECTIONAL : DMA_TO_DEVICE);

Write some simple wrapper for this pattern.

Thanks