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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aUWNlTAmbSTXsBDE@google.com>
Date: Fri, 19 Dec 2025 09:38:29 -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 Fri, Dec 19, 2025, Teddy Astie wrote:
> Le 19/12/2025 à 02:04, Ariadne Conill a écrit :
> > Xen domU cannot access the given MMIO address for security reasons,
> > resulting in a failed hypercall in ioremap() due to permissions.
> >
> > Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset")
> > Signed-off-by: Ariadne Conill <ariadne@...adne.space>
> > Cc: xen-devel@...ts.xenproject.org
> > Cc: stable@...r.kernel.org
> > ---
> >   arch/x86/kernel/cpu/amd.c | 6 ++++++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> > index a6f88ca1a6b4..99308fba4d7d 100644
> > --- a/arch/x86/kernel/cpu/amd.c
> > +++ b/arch/x86/kernel/cpu/amd.c
> > @@ -29,6 +29,8 @@
> >   # include <asm/mmconfig.h>
> >   #endif
> >
> > +#include <xen/xen.h>
> > +
> >   #include "cpu.h"
> >
> >   u16 invlpgb_count_max __ro_after_init = 1;
> > @@ -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.  The right behavior there is to configure a
reserved NPT entry to reflect the access into the guest as a #VC.