linux-kernel - Re: [PATCH] x86/CPU/AMD: avoid printing reset reasons on Xen domU

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] [day] [month] [year] [list]

Message-ID: <aUln5DdCMcvhJzl9@google.com>
Date: Mon, 22 Dec 2025 07:46:44 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Teddy Astie <teddy.astie@...es.tech>
Cc: Ariadne Conill <ariadne@...adne.space>, linux-kernel@...r.kernel.org, 
	mario.limonciello@....com, darwi@...utronix.de, sandipan.das@....com, 
	kai.huang@...el.com, me@...aill.net, yazen.ghannam@....com, riel@...riel.com, 
	peterz@...radead.org, hpa@...or.com, x86@...nel.org, tglx@...utronix.de, 
	mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, 
	xen-devel@...ts.xenproject.org, stable@...r.kernel.org
Subject: Re: [PATCH] x86/CPU/AMD: avoid printing reset reasons on Xen domU

On Sat, Dec 20, 2025, Teddy Astie wrote:
> Le 19/12/2025 à 18:40, Sean Christopherson a écrit :
> > On Fri, Dec 19, 2025, Teddy Astie wrote:
> >>> @@ -1333,6 +1335,10 @@ static __init int print_s5_reset_status_mmio(void)
> >>>    	if (!cpu_feature_enabled(X86_FEATURE_ZEN))
> >>>    		return 0;
> >>>
> >>> +	/* Xen PV domU cannot access hardware directly, so bail for domU case */
> >>> +	if (cpu_feature_enabled(X86_FEATURE_XENPV) && !xen_initial_domain())
> >>> +		return 0;
> >>> +
> >>>    	addr = ioremap(FCH_PM_BASE + FCH_PM_S5_RESET_STATUS, sizeof(value));
> >>>    	if (!addr)
> >>>    		return 0;
> >>
> >> Such MMIO only has a meaning in a physical machine, but the feature
> >> check is bogus as being on Zen arch is not enough for ensuring this.
> >>
> >> I think this also translates in most hypervisors with odd reset codes
> >> being reported; without being specific to Xen PV (Zen CPU is
> >> unfortunately not enough to ensuring such MMIO exists).
> >>
> >> Aside that, attempting unexpected MMIO in a SEV-ES/SNP guest can cause
> >> weird problems since they may not handled MMIO-NAE and could lead the
> >> hypervisor to crash the guest instead (unexpected NPF).
> >
> > IMO, terminating an SEV-ES+ guest because it accesses an unknown MMIO range is
> > unequivocally a hypervisor bug.
> 
> Terminating may be a bit excessive, but the hypervisor can respond #GP
> to either unexpected MMIO-NAE and NPF-AE if it doesn't know how to deal
> with this MMIO/NPF (xAPIC has a similar behavior when it is disabled).

Maybe with a very liberal interpretation of AMD specs, e.g. to mimic the reserved
HyperTransport region behavior.  Defining a virtual platform/bus that #GPs on
accesses to any "unknown" MMIO region would be incredibly hostile behavior for
a hypervisor.

> > The right behavior there is to configure a reserved NPT entry
> > to reflect the access into the guest as a #VC.
> 
> I'm not sure this is the best approach, that would allow the guest to
> trick the hypervisor into making a unbounded amount of reserved entries.

No, the maximum number of reserved entries is bounded by the number of vCPUs in
the VM, because each reserved entry only needs to exist long enough to refect
the access into the guest.  Recycling NPT page tables after every MMIO-NAE would
be comically agressively, but it's very doable for a hypervisor to set a reasonable
limit on the number of NPT page tables it creates for a VM.