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: <a5c4dd0b-d524-43d5-8d33-0aad02adc541@ariadne.space>
Date: Fri, 19 Dec 2025 15:19:28 -0800
From: Ariadne Conill <ariadne@...adne.space>
To: Sean Christopherson <seanjc@...gle.com>, Borislav Petkov <bp@...en8.de>
Cc: 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

Hi,

On 12/19/25 08:09, Sean Christopherson wrote:
> 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.

Yes, which results in the guest panicing on Zen platforms.

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

Nothing :)

At Edera we have been running with this patch for a few months, I just 
forgot to upstream it.

I was reminded of this patch when an Alpine user opened a bug[0] 
demonstrating the same behavior on 6.18.

[0]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17789

> 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.

I think it would be better to fix this in a more generic way if we can.

Ariadne