linux-kernel - Re: [PATCH 0/4] dma-buf: add revoke mechanism to invalidate shared buffers

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eed9fd4c-ca36-4f6a-af10-56d6e0997d8c@amd.com>
Date: Mon, 12 Jan 2026 11:04:38 +0100
From: Christian König <christian.koenig@....com>
To: Leon Romanovsky <leon@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>,
 Sumit Semwal <sumit.semwal@...aro.org>, 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: Re: [PATCH 0/4] dma-buf: add revoke mechanism to invalidate shared
 buffers

On 1/11/26 11:37, Leon Romanovsky wrote:
> 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.

We already have that. This is what the move_notify is all about.

> 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.

It's not correct that there is no DMA-buf handling for this use case.

> 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.

As far as I can see that patch set is completely superfluous.

The move_notify mechanism has been implemented exactly to cover this use case and is in use for a couple of years now.

What exactly is missing?

Regards,
Christian.

> 
> 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>
>