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

Message-ID: <aUV4u0r44V5zHV5f@google.com>
Date: Fri, 19 Dec 2025 08:09:31 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Borislav Petkov <bp@...en8.de>
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, 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, Borislav Petkov wrote:
> On December 19, 2025 1:01:31 AM UTC, Ariadne Conill <ariadne@...adne.space> wrote:
> >Xen domU cannot access the given MMIO address for security reasons,
> >resulting in a failed hypercall in ioremap() due to permissions.

Why does that matter though?  Ah, because set_pte() assumes success, and so
presumably the failed hypercall goes unnoticed and trying to access the MMIO
#PFs due to !PRESENT mapping.

> >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 */

Heh, Xen on Zen crime.

> >+	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;
> 
> Sean, looka here. The other hypervisor wants other checks.
>
> Time to whip out the X86_FEATURE_HYPERVISOR check.

LOL, Ariadne, be honest, how much did Boris pay you?  :-D

Jokes aside, I suppose I'm fine adding a HYPERVISOR check, but at the same time,
how is this not a Xen bug?  Refusing to create a mapping because the VM doesn't
have a device defined at a given GPA is pretty hostile behavior for a hypervisor.