From: Dmytro Maluka <dmaluka@chromium.org>
To: David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
iommu@lists.linux.dev
Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
linux-kernel@vger.kernel.org,
"Vineeth Pillai (Google)" <vineeth@bitbyteword.org>,
Aashish Sharma <aashish@aashishsharma.net>,
Grzegorz Jaszczyk <jaszczyk@chromium.org>,
Chuanxiao Dong <chuanxiao.dong@intel.com>,
Kevin Tian <kevin.tian@intel.com>,
Dmytro Maluka <dmaluka@chromium.org>
Subject: [PATCH 0/2] iommu/vt-d: Ensure memory ordering in context & root entry updates
Date: Sun, 21 Dec 2025 02:43:00 +0100 [thread overview]
Message-ID: <20251221014302.17738-1-dmaluka@chromium.org> (raw)
As discussed in [1], we don't currently prevent the compiler from
reordering memory writes when updating context entries, which is
potentially dangerous, as it may cause setting the present bit (i.e.
enabling DMA translation for the given device) before finishing setting
up other bits in the context entry (and thus creating a time window when
a DMA from the device may result in an unpredicted behavior).
Fix this in the same way as how this is already addressed for PASID
entries, i.e. by using READ_ONCE/WRITE_ONCE in the helpers used for
setting individual bits in context entries, so that memory writes done
by those helpers are ordered in relation to each other (plus, prevent
load/store tearing and so on).
While at it, similarly paranoidally fix updating root entries as well:
use WRITE_ONCE to make sure that the present bit is set atomically
together with the context table address bits, not before them.
[1] https://lore.kernel.org/all/aTG7gc7I5wExai3S@google.com/
Dmytro Maluka (2):
iommu/vt-d: Ensure memory ordering in context entry updates
iommu/vt-d: Use WRITE_ONCE for setting root table entries
drivers/iommu/intel/iommu.c | 2 +-
drivers/iommu/intel/iommu.h | 37 +++++++++++++++++++++----------------
drivers/iommu/intel/pasid.c | 3 ++-
3 files changed, 24 insertions(+), 18 deletions(-)
--
2.47.3
next reply other threads:[~2025-12-21 1:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-21 1:43 Dmytro Maluka [this message]
2025-12-21 1:43 ` [PATCH 1/2] iommu/vt-d: Ensure memory ordering in context entry updates Dmytro Maluka
2025-12-21 9:04 ` Baolu Lu
2025-12-21 13:11 ` Dmytro Maluka
2025-12-23 6:10 ` Baolu Lu
2025-12-27 18:06 ` Dmytro Maluka
2025-12-21 1:43 ` [PATCH 2/2] iommu/vt-d: Use WRITE_ONCE for setting root table entries Dmytro Maluka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251221014302.17738-1-dmaluka@chromium.org \
--to=dmaluka@chromium.org \
--cc=aashish@aashishsharma.net \
--cc=baolu.lu@linux.intel.com \
--cc=chuanxiao.dong@intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jaszczyk@chromium.org \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=vineeth@bitbyteword.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox