[PATCH rdma-next 06/15] RDMA/umem: Map CQ buffers DMA_FROM_DEVICE

[Yishai Hadas <yishaih@nvidia.com>]

ib_umem_get_cq_buf() / ib_umem_get_cq_buf_or_va() pass DMA_FROM_DEVICE
explicitly, overriding the default DMA_BIDIRECTIONAL mapping. CQ callers
pass IB_ACCESS_LOCAL_WRITE, which only means the umem must be pinned
writable for GUP purposes; it says nothing about which side of the PCIe
link actually touches the memory. For a CQ ring the device writes CQEs
and the CPU only reads, the opposite of what IB_ACCESS_LOCAL_WRITE
conventionally implies for MR/WQE buffers.  Deriving the direction from
access flags the way the following patch does for other buffer types
would give DMA_BIDIRECTIONAL here (ib_access_writable() treats
IB_ACCESS_LOCAL_WRITE as writable), identical to today's unconditional
behaviour, and CQ buffers would get none of this hardening -- hence the
explicit override instead.

For dmabuf buffers the direction is managed by the dmabuf subsystem and
ib_umem_get_desc() routes them unchanged, ignoring the derived
direction.

All drivers that call the CQ pinning functions benefit automatically:
mlx5, mlx4, efa, bnxt_re, ionic, qedr, mana, erdma, and hns -- including
CQ resize and legacy VA-only creation paths, since an earlier commit
already routed all of them through ib_umem_get_cq_buf_or_va() instead of
the generic ib_umem_get_va(). vmw_pvrdma's CQ was deliberately left on
the generic path by that same commit for its own embedded ring-state
reason, and continues to correctly derive DMA_BIDIRECTIONAL there.

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 reading write-only buffers (CQ ring),
    limiting information leakage.
  - Standard deployments without IOMMU direction enforcement: no
    practical security effect today, but the correct semantic
    declaration and zero runtime cost.

Note: the CPU does not write to the CQ ring buffer; the CQ
consumer-index doorbell update goes through the UAR (MMIO), not through
this DMA-mapped buffer.

Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
---
 drivers/infiniband/core/umem.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index c2f277ada042..f1da70c4e352 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -587,6 +587,9 @@ static int uverbs_create_cq_get_buffer_desc(const struct uverbs_attr_bundle *att
  * must arrange its own backing (typically an in-kernel allocation)
  * when no source is available.
  *
+ * The buffer is mapped DMA_FROM_DEVICE: the NIC writes CQEs into it
+ * and the CPU only reads.
+ *
  * Return: caller-owned umem on success; NULL when no source supplied
  * a buffer; ERR_PTR(...) on error.
  */
@@ -597,7 +600,7 @@ struct ib_umem *ib_umem_get_cq_buf(struct ib_device *device,
 	return ib_umem_get_from_attrs(device, attrs,
 				      UVERBS_ATTR_CREATE_CQ_BUF_UMEM,
 				      uverbs_create_cq_get_buffer_desc,
-				      size, access, DMA_BIDIRECTIONAL);
+				      size, access, DMA_FROM_DEVICE);
 }
 EXPORT_SYMBOL(ib_umem_get_cq_buf);
 
@@ -613,6 +616,9 @@ EXPORT_SYMBOL(ib_umem_get_cq_buf);
  * Like ib_umem_get_cq_buf(), but pins @addr/@size when neither the
  * UMEM attribute nor the legacy CQ buffer attributes are supplied.
  *
+ * The buffer is mapped DMA_FROM_DEVICE: the NIC writes CQEs into it
+ * and the CPU only reads.
+ *
  * See ib_umem_get_attr_or_va() for the note on @size's dual role and
  * the migration path for drivers that would distinguish a user-supplied
  * length from a driver-computed minimum.
@@ -626,7 +632,7 @@ struct ib_umem *ib_umem_get_cq_buf_or_va(struct ib_device *device,
 	return ib_umem_get_from_attrs_or_va(device, attrs,
 					    UVERBS_ATTR_CREATE_CQ_BUF_UMEM,
 					    uverbs_create_cq_get_buffer_desc,
-					    addr, size, access, DMA_BIDIRECTIONAL);
+					    addr, size, access, DMA_FROM_DEVICE);
 }
 EXPORT_SYMBOL(ib_umem_get_cq_buf_or_va);
 
-- 
2.18.1