lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com>
Date: Sun, 11 Jan 2026 12:37:07 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>,
	Leon Romanovsky <leon@...nel.org>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	Christian König <christian.koenig@....com>,
	Alex Williamson <alex@...zbot.org>,
	Kevin Tian <kevin.tian@...el.com>,
	Joerg Roedel <joro@...tes.org>,
	Will Deacon <will@...nel.org>,
	Robin Murphy <robin.murphy@....com>
Cc: linux-rdma@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	linaro-mm-sig@...ts.linaro.org,
	kvm@...r.kernel.org,
	iommu@...ts.linux.dev
Subject: [PATCH 0/4] dma-buf: add revoke mechanism to invalidate shared buffers

This series implements a dma-buf “revoke” mechanism: to allow a dma-buf
exporter to explicitly invalidate (“kill”) a shared buffer after it has
been distributed to importers, so that further CPU and device access is
prevented and importers reliably observe failure.

Today, dma-buf effectively provides “if you have the fd, you can keep using
the memory indefinitely.” That assumption breaks down when an exporter must
reclaim, reset, evict, or otherwise retire backing memory after it has been
shared. Concrete cases include GPU reset and recovery where old allocations
become unsafe to access, memory eviction/overcommit where backing storage
must be withdrawn, and security or isolation situations where continued access
must be prevented. While drivers can sometimes approximate this with
exporter-specific fencing and policy, there is no core dma-buf state transition
that communicates “this buffer is no longer valid; fail access” across all
access paths.

The change in this series is to introduce a core “revoked” state on the dma-buf
object and a corresponding exporter-triggered revoke operation. Once a dma-buf
is revoked, new access paths are blocked so that attempts to DMA-map, vmap, or
mmap the buffer fail in a consistent way.

In addition, the series aims to invalidate existing access as much as the kernel
allows: device mappings are torn down where possible so devices and IOMMUs cannot
continue DMA.

The semantics are intentionally simple: revoke is a one-way, permanent transition
for the lifetime of that dma-buf instance.

>From a compatibility perspective, users that never invoke revoke are unaffected,
and exporters that adopt it gain a core-supported enforcement mechanism rather
than relying on ad hoc driver behavior. The intent is to keep the interface
minimal and avoid imposing policy; the series provides the mechanism to terminate
access, with policy remaining in the exporter and higher-level components.

BTW, see this megathread [1] for additional context.  
Ironically, it was posted exactly one year ago.

[1] https://lore.kernel.org/all/20250107142719.179636-2-yilun.xu@linux.intel.com/

Thanks

Cc: linux-rdma@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Cc: linux-media@...r.kernel.org
Cc: dri-devel@...ts.freedesktop.org
Cc: linaro-mm-sig@...ts.linaro.org
Cc: kvm@...r.kernel.org
Cc: iommu@...ts.linux.dev
To: Jason Gunthorpe <jgg@...pe.ca>
To: Leon Romanovsky <leon@...nel.org>
To: Sumit Semwal <sumit.semwal@...aro.org>
To: Christian König <christian.koenig@....com>
To: Alex Williamson <alex@...zbot.org>
To: Kevin Tian <kevin.tian@...el.com>
To: Joerg Roedel <joro@...tes.org>
To: Will Deacon <will@...nel.org>
To: Robin Murphy <robin.murphy@....com>

Signed-off-by: Leon Romanovsky <leonro@...dia.com>
---
Leon Romanovsky (4):
      dma-buf: Introduce revoke semantics
      vfio: Use dma-buf revoke semantics
      iommufd: Require DMABUF revoke semantics
      iommufd/selftest: Reuse dma-buf revoke semantics

 drivers/dma-buf/dma-buf.c          | 36 ++++++++++++++++++++++++++++++++----
 drivers/iommu/iommufd/pages.c      |  2 +-
 drivers/iommu/iommufd/selftest.c   | 12 ++++--------
 drivers/vfio/pci/vfio_pci_dmabuf.c | 27 ++++++---------------------
 include/linux/dma-buf.h            | 31 +++++++++++++++++++++++++++++++
 5 files changed, 74 insertions(+), 34 deletions(-)
---
base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
change-id: 20251221-dmabuf-revoke-b90ef16e4236

Best regards,
--  
Leon Romanovsky <leonro@...dia.com>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ