linux-kernel - RE: [PATCH v2 2/2] vfio/type1: Set IOMMU_MMIO in dma->prot for MMIO-backed addresses

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:
 <SI2PR01MB43930E5D802B02D3FCD5ED9ADCC3A@SI2PR01MB4393.apcprd01.prod.exchangelabs.com>
Date: Fri, 7 Nov 2025 02:38:50 +0000
From: Wei Wang <wei.w.wang@...mail.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: "alex@...zbot.org" <alex@...zbot.org>, "suravee.suthikulpanit@....com"
	<suravee.suthikulpanit@....com>, "thomas.lendacky@....com"
	<thomas.lendacky@....com>, "joro@...tes.org" <joro@...tes.org>,
	"kevin.tian@...el.com" <kevin.tian@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "iommu@...ts.linux.dev"
	<iommu@...ts.linux.dev>
Subject: RE: [PATCH v2 2/2] vfio/type1: Set IOMMU_MMIO in dma->prot for
 MMIO-backed addresses

On Friday, November 7, 2025 9:04 AM, Jason Gunthorpe wrote:
> On Mon, Nov 03, 2025 at 10:00:34PM +0800, Wei Wang wrote:
> > Before requesting the IOMMU driver to map an IOVA to a physical
> > address, set the IOMMU_MMIO flag in dma->prot when the physical
> > address corresponds to MMIO. This allows the IOMMU driver to handle
> MMIO mappings specially.
> > For example, on AMD CPUs with SME enabled, the AMD IOMMU driver
> avoids
> > setting the C-bit if iommu_map() is called with IOMMU_MMIO set in prot.
> > This prevents issues with PCIe P2P communication, since current PCIe
> > switches and devices do not interpret the C-bit correctly.
> >
> > Signed-off-by: Wei Wang <wei.w.wang@...mail.com>
> > ---
> >  drivers/vfio/vfio_iommu_type1.c | 14 +++++++++-----
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> This may be the best you can do with vfio type1, but just because the VMA is
> special doesn't necessarily mean it is MMIO, nor does it mean it is decrypted
> memory.

I think here vfio type1 only needs to provide the info about "MMIO or not"
(the decision to encrypt MMIO or not rests with the vendor IOMMU driver).

Why might a region not be MMIO when vma->flags includes VM_IO | VM_PFNMAP?
(are you aware of any real examples in use?)

For reference, BAR MMIO regions are explicitly mapped with these flags in
vfio_pci_core_mmap() :
	 vm_flags_set(vma, VM_ALLOW_ANY_UNCACHED | VM_IO | VM_PFNMAP |
             		            VM_DONTEXPAND | VM_DONTDUMP);"

The only exception I can think of is nested virtualization, where an emulated device (with
vMMIO emulated using system RAM) is passed through to a nested guest. But this might
not be commonly used in practice (no performance gain as physical device pass through),
and the lack of encryption for such vMMIO should not be a concern, IMHO. Its security
model aligns essentially with that of the host (i.e., physical MMIO data is not encrypted
on the host, and the same principle applies to emulated vMMIO in nested environments).
Also the same for physical devices (as opposed to virtual devices) passed to a nested guest.

> 
> I think to really make this work fully properly going forward people are going
> to have to use iommufd's dmabuf.

Yeah, I'll also patch for iommufd. We still need to account for the case that many users are
still relying on legacy VFIO type1 (will also have some backport work of this patch).