linux-kernel - Virtio-IOMMU interrupt remapping design

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: <a65d955c-192b-4e79-ab11-8e2af78b62af@gmail.com>
Date: Sun, 15 Jun 2025 14:47:15 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: "Michael S. Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>,
 Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez
 <eperezma@...hat.com>, "Rafael J. Wysocki" <rafael@...nel.org>,
 Len Brown <lenb@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
 Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
 Robin Murphy <robin.murphy@....com>, Alyssa Ross <hi@...ssa.is>
Cc: virtualization@...ts.linux.dev, linux-kernel@...r.kernel.org,
 linux-acpi@...r.kernel.org, iommu@...ts.linux.dev, x86@...nel.org,
 Spectrum OS Development <devel@...ctrum-os.org>
Subject: Virtio-IOMMU interrupt remapping design

Virtio-IOMMU interrupt remapping turned out to be much harder than I
realized.  The main problem is that interrupt remapping is set up
very early in boot.  In fact, Linux calls the interrupt remapping probe
function from the APIC initialization code: x86_64_probe_apic ->
enable_IR_x2apic -> irq_remapping_prepare().  This is almost certainly
much before PCI has been initialized.  Also, the order in which devices
will be initialized is not something Linux guarantees at all, which is a
problem because interrupt remapping must be initialized before drivers
start setting up interrupts.  Otherwise, the interrupt remapping table
won't include entries for already-existing interrupts, and things will
either break badly, not get the benefit of interrupt remapping
security-wise, or both.

The reason I expect this doesn't cause problems for address translation
is that the IOMMU probably starts in bypass mode by default, meaning
that all DMA is permitted.  If the IOMMU is only used by VFIO or
IOMMUFD, it will not be needed until userspace starts up, which is after
the IOMMU has been initialized.  This isn't ideal, though, as it means
that kernel drivers operate without DMA protection.

Is a paravirtualized IOMMU with interrupt remapping something that makes
sense?  Absolutely!  However, the IOMMU should be considered a platform
device that must be initialized very early in boot.  Using virtio-IOMMU
with MMIO transport as the interface might be a reasonable option, but
the IOMMU needs to be enumerated via ACPI, device tree, or kernel
command line argument.  This allows it to be brought up before anything
capable of DMA is initialized.

Is this the right path to go down?  What do others think about this?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)