From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f66.google.com (mail-qv1-f66.google.com [209.85.219.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0A102BEC3F for ; Mon, 19 Jan 2026 16:58:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.66 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768841927; cv=none; b=Eu9jp3BB0Xh9nJ4Hm/VPWmhbJ5yGqXFVznqOqlJjOXqQv1003kQ7lz6qsljJ9SBTdMfxlFtMcCj7xCbrl/i+wLxGPbsvmkM4Tz0zvuM29ebG/NLQzYyRYGuFVO7oTMpLhTmJrlRPZrkcMydxFGXn3eGccniNundiPcMWyxnlB4k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768841927; c=relaxed/simple; bh=nsqjKuZBX2xVAZ9wDedc6M6Km3uKRKGPzdUMml50yUo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NEZ740WU52A04hPtdRYekZNX7olBhc163OG2+uoAedvxv/jvf1ozWYUn4elJLBxNVJcGyMS0V+svDYVem397DayhrWC4wRaklyTy4BdY0Wm8GOoUSwUUqOJLoN4X7ErnjhW9UOyK+TdVpls7Xrza2RyxnvmAq7TmxMuQFUF1iCg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=LA4MQ6LH; arc=none smtp.client-ip=209.85.219.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="LA4MQ6LH" Received: by mail-qv1-f66.google.com with SMTP id 6a1803df08f44-88a3d2f3299so46752196d6.2 for ; Mon, 19 Jan 2026 08:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1768841925; x=1769446725; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=ljxKTxaVdu8I0ces4FnKFMKgo+H8JcchtOlXOe2X8IE=; b=LA4MQ6LHmA3jMregg3JwmBDrlNIC6TKyIIRoqsj/MeU1Dsh3Q71mCDdmTdHoGQtVsN ZRrHL9mWWJsxeN2FDE1Hjtj6PvZ0arDGUT1e9HZIsSvIjnYe2SpfFRD5sasqcKL3JyXl aXI23p8ZI+7yyjhTbA4fRhrjxEC6exVDsBNDz+P/kmEtSJV/CknvREmwrZDJHWYUyb2E mNm2hs1qb8JDJ2XVCs7DEo3chAG5VztyMJLYH9BsfjRnrxw4x2H9PKSoWLzxnrG26WNg OrhsagYWLmM4Ktp7WrpWShtGcDuHTGATcf0yOQitnpMXIYgJTMfX9eYKKquGpVpl2F4D tA4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768841925; x=1769446725; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ljxKTxaVdu8I0ces4FnKFMKgo+H8JcchtOlXOe2X8IE=; b=Go/LkUBTYO9SwRUjRHIh8XczfmOeUMcz1IrhsM3RudlrxXnPsXh6apkW9FhawUN7FE RQbBvzqTKSIZl9Js5XPwRa3i4rPrLYc5Fp8gbpqGxoLmhblQfJYt6et5mB0Sc/uneEhi W+jzSpROF7FWVtZCtv2L4LINYuM65Kw/3ibSls2gfuZtoP6I0NHMSqavKSMuz2/LZloe Em3MxKzATb7JWz6K7jO2aeEiJcXINe+caK0rHj4bNfRa25qNxi/T6q4bFJpOaHblRw8d w4lgMNho5oZbLyOSCqOFMewsUa8zy2vt2EmSqQWuyLlJBDXRKFxVC2jyIEbyDRMjqTrJ rzag== X-Forwarded-Encrypted: i=1; AJvYcCWuyX8XdGmJpfUWJatcyDdK/ICDJ6Rnf8eebBysk3uausHu3lIyhfF7MMGP/u0/gPFwjWxKLWxFAbCrG4Q=@vger.kernel.org X-Gm-Message-State: AOJu0YxdNxNPtRr7yKbtM6cMi00JS47TJ24fJfuvtByPWpNirSYk1vEO AlZMmKQUk5UcMAxwvL1G1dCg6sHf5xBJsboZne1gWj11xTcU0uBiHbaRdSv07eAsvTc= X-Gm-Gg: AZuq6aIOo2eseekbN63FyzuqNQl75mEkSB/0Dbg4jWk/qqQuoyI1I8bSUhQ0wxk1Bj0 s1TrbCzJh97Jca+omkosYpdCRQpfCBcjOQK3puJ394MfHUEB2dqhzEUF2M1hyC0cW4oQ5zqbnw7 Y5p9l8bUmwWu6Q+O44ib1nzU//RS9yPQcXC4U7kgLqhwKKNCNtWvPK2JkmODLztkvX4njMi/l7Y 3IAPWPUmOJ/3+YhoLgPz6tIQ38CDrVe0Xh5Ug8NPzR4kdnhXJ85rLFvaXhvDYoQI98VRXRApbl4 xW/COWAucFFJilNNfzYRgYhfnX/CkJZ5BMhqzMy5WMq74Ti7YbSx7R2sLQ3A1m6Fp5tejJZO7kp TpOGnjzzjcLuB/qJTUX07GG1+Hh1ARhX7IcCHyxN+y31HFs4blz2Zbxj5afyfylOGTZLqQqdEim tWVtGiCAJlJP+HilSj9/8J6yg17Pjp0Q3WVWM3zSZjD+S5y+cpO2om/CfdJQRYJoKK9YYc/by1h 2kruw== X-Received: by 2002:a05:6214:2523:b0:88a:2e39:957e with SMTP id 6a1803df08f44-8942dd9e90fmr129930286d6.57.1768841924690; Mon, 19 Jan 2026 08:58:44 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8942e5e526dsm87021366d6.12.2026.01.19.08.58.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 08:58:44 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vhsaR-00000005IQb-2Wqn; Mon, 19 Jan 2026 12:58:43 -0400 Date: Mon, 19 Jan 2026 12:58:43 -0400 From: Jason Gunthorpe To: Leon Romanovsky Cc: Sumit Semwal , Christian =?utf-8?B?S8O2bmln?= , Alex Deucher , David Airlie , Simona Vetter , Gerd Hoffmann , Dmitry Osipenko , Gurchetan Singh , Chia-I Wu , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Lucas De Marchi , Thomas =?utf-8?Q?Hellstr=C3=B6m?= , Rodrigo Vivi , Kevin Tian , Joerg Roedel , Will Deacon , Robin Murphy , Alex Williamson , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, virtualization@lists.linux.dev, intel-xe@lists.freedesktop.org, linux-rdma@vger.kernel.org, iommu@lists.linux.dev, kvm@vger.kernel.org Subject: Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Message-ID: <20260119165843.GH961572@ziepe.ca> References: <20260118-dmabuf-revoke-v2-0-a03bb27c0875@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260118-dmabuf-revoke-v2-0-a03bb27c0875@nvidia.com> On Sun, Jan 18, 2026 at 02:08:44PM +0200, Leon Romanovsky wrote: > Changelog: > v2: > * Changed series to document the revoke semantics instead of > implementing it. > v1: https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com > > ------------------------------------------------------------------------- > This series documents 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. > > The change in this series is to properly document and use existing 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. I think it would help to explain the bigger picture in the cover letter: DMABUF has quietly allowed calling move_notify on pinned DMABUFs, even though legacy importers using dma_buf_attach() would simply ignore these calls. RDMA saw this and needed to use allow_peer2peer=true, so implemented a new-style pinned importer with an explicitly non-working move_notify() callback. This has been tolerable because the existing exporters are thought to only call move_notify() on a pinned DMABUF under RAS events and we have been willing to tolerate the UAF that results by allowing the importer to continue to use the mapping in this rare case. VFIO wants to implement a pin supporting exporter that will issue a revoking move_notify() around FLRs and a few other user triggerable operations. Since this is much more common we are not willing to tolerate the security UAF caused by interworking with non-move_notify() supporting drivers. Thus till now VFIO has required dynamic importers, even though it never actually moves the buffer location. To allow VFIO to work with pinned importers, according to how DMABUF was intended, we need to allow VFIO to detect if an importer is legacy or RDMA and does not actually implement move_notify(). Introduce a new function that exporters can call to detect these less capable importers. VFIO can then refuse to accept them during attach. In theory all exporters that call move_notify() on pinned DMABUF's should call this function, however that would break a number of widely used NIC/GPU flows. Thus for now do not spread this further than VFIO until we can understand how much of RDMA can implement the full semantic. In the process clarify how move_notify is intended to be used with pinned DMABUFs. Jason