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: <20251107163614.GN1732817@nvidia.com>
Date: Fri, 7 Nov 2025 12:36:14 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Wei Wang <wei.w.wang@...mail.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 Fri, Nov 07, 2025 at 04:19:35PM +0000, Wei Wang wrote:
> On Friday, November 7, 2025 11:57 PM, Jason Gunthorpe wrote:
> On Fri, Nov 07, 2025 at 03:49:17PM +0000, Wei Wang wrote:
> >    > (are you aware of any real examples in use?)
> >    > VM_IO should indicate MMIO, yes, but we don't actually check that in
> >    > this type 1 path..
> 
> >    Is it because VFIO type1 didn’t need to check for MMIO before?
> >    (not sure how this impacts this patch adding the VM_IO check for MMIO
> >    :) )
> 
> > Okay, but it still doesn't mean it has to be decrypted..
> 
> I think "decrypted or not" is the job of the 1st patch. For now,
> MMIO cannot be encrypted, particularly not via sme_set(). If MMIO
> encryption is ever introduced in the future, a new flag (probably
> different from sme_me_mask) would need to be added.

The kernel is using "decrypted" as some weirdo code-word to mean the
memory is shared with the hypervisor. Only on AMD does it even have
anything to do with actual memory encryption.

However when I look at swiotlb and dma coherent mmap I see it calls
set_memory_decrypted(), uses pgprot_decrypted(), but still uses
__sme_set() when forming the iommu page table??

So why is that OK, but MMIO needs to avoid the sme_set() in the iommu
page table?

IOW I would like to hear from AMD some clear rules when sme_set needs
to be called and when it isn't.

Then we can decide if VM_IO is sufficient and so on.

Jason