linux-kernel - [PATCH v2 0/3] iommu/vt-d: Ensure atomicity in context and PASID entry updates

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-next>] [day] [month] [year] [list]

Message-ID: <20260120061816.2132558-1-baolu.lu@linux.intel.com>
Date: Tue, 20 Jan 2026 14:18:11 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: Joerg Roedel <joro@...tes.org>,
	Will Deacon <will@...nel.org>,
	Robin Murphy <robin.murphy@....com>,
	Kevin Tian <kevin.tian@...el.com>,
	Jason Gunthorpe <jgg@...dia.com>
Cc: Dmytro Maluka <dmaluka@...omium.org>,
	Samiullah Khawaja <skhawaja@...gle.com>,
	iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Lu Baolu <baolu.lu@...ux.intel.com>
Subject: [PATCH v2 0/3] iommu/vt-d: Ensure atomicity in context and PASID entry updates

This is a follow-up from recent discussions in the iommu community
mailing list [1] [2] regarding potential race conditions in table
entry updates.

The Intel VT-d hardware fetches translation table entries (context
entries and PASID entries) in 128-bit (16-byte) chunks. Currently, the
Linux driver often updates these entries using multiple 64-bit writes.
This creates a race condition where the IOMMU hardware may fetch a
"torn" entry — a mixture of old and new data — during a CPU update. This
can lead to unpredictable hardware behavior, spurious faults, or system
instability.

This addresses these atomicity issues by following the translation table
entry ownership handshake protocal recommended by the VT-d specification.

[1] https://lore.kernel.org/linux-iommu/20251227175728.4358-1-dmaluka@chromium.org/
[2] https://lore.kernel.org/linux-iommu/20260107201800.2486137-1-skhawaja@google.com/

Change log:

v2:
 - Considering that these fixes should be backported deep into old
   versions, and the previous solution relies heavily on the x86_64
   cmpxchg16b instruction, which is not friendly to backport as it might
   cause regressions on early hardware or configurations, we use the
   simple dma_wmb() approach in this version.
 - Jason proposed the entry-sync framework
   (https://lore.kernel.org/linux-iommu/20260113150542.GF812923@nvidia.com/)
   which consolidates the details of how to update a translation table
   entry in common code shared by the individual drivers, so that the
   IOMMU driver could be designed without considering the hitless or
   non-hitless replace.
 - To make life easier, I decided to split all the work into multiple
   series. The first, as it is, covers fixing the real problems in a
   backport-friendly way, and the next series covers entry-sync for
   PASID table entry updates.

v1: https://lore.kernel.org/linux-iommu/20260113030052.977366-1-baolu.lu@linux.intel.com/

Lu Baolu (3):
  iommu/vt-d: Clear Present bit before tearing down PASID entry
  iommu/vt-d: Clear Present bit before tearing down context entry
  iommu/vt-d: Fix race condition during PASID entry replacement

 drivers/iommu/intel/iommu.h  |  21 +++-
 drivers/iommu/intel/pasid.h  |  28 +++---
 drivers/iommu/intel/iommu.c  |  33 +++---
 drivers/iommu/intel/nested.c |   9 +-
 drivers/iommu/intel/pasid.c  | 190 +----------------------------------
 5 files changed, 58 insertions(+), 223 deletions(-)

-- 
2.43.0