linux-kernel - Re: [PATCH v1] iommu/amd: Set C-bit only for RAM-backed PTEs in IOMMU page tables

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:
 <SI2PR01MB43936BE606220BBABCFA30DCDCF1A@SI2PR01MB4393.apcprd01.prod.exchangelabs.com>
Date: Fri, 24 Oct 2025 14:23:54 +0000
From: Wei Wang <wei.w.wang@...mail.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: "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 v1] iommu/amd: Set C-bit only for RAM-backed PTEs in IOMMU
 page tables

On Friday, October 24, 2025 11:40 AM, Jason Gunthorpe wrote:
> It is not a santiy check, a sanity check would fail the mapping. This
> is changing what PTE is created by trying to guess properties about
> the pfn.

It's a check and handling for now. If, later, it becomes necessary for callers
to pass an IOMMU_* flag to request the Private bit and upon the
check (via page_is_ram) failure, an error will be returned to the caller. 

> IOMMU driver to validate whether a user-supplied address _can_ be mapped
> with the Private bit (RAM is the case that "can" currently, and since the driver
> can already determine whether a PFN is RAM or not, I'm not sure why it needs
> an interface for users to tell the driver).

> As I understand AMD's architecture the hypervisor runs with all ram as
> encrypted and has to set the C bit for any dram. The MMIO is only
> protected by the RMP and does not have a C bit set.

> So even in a TDISP world with private MMIO we still end up with
> system DRAM being treated differently than MMIO.

Yes. In fact, the mentioned P2P broken issue also occurs on the host (this
is the primary case that the patch aims to address). The SME feature is used
in the host/native environment (not discussing the SNP guest case), and in
this context the C-bit is added to the host physical address.

> It really does seem like IOMMU_MMIO is the right direction here.

> Again we should not be trying to guess if something is "ram" or not
> deep inside the iommu code. We have IOMMU_MMIO specifically to tell
> the iommu if it is ram or not.

Sorry I think my main confusion here is why this is considered a ‘guess’ of RAM.
The function page_is_ram() clearly returns whether it is RAM, right? If so,
why is there a need to add an interface and require users (e.g., p2pdma,
vfio etc.) to tell the IOMMU driver that it is RAM or not?