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: <e2632ad6-6721-4697-a923-53b5bb0c9f0f@citrix.com>
Date: Fri, 19 Dec 2025 16:26:07 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Sean Christopherson <seanjc@...gle.com>, Borislav Petkov <bp@...en8.de>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>,
 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 19/12/2025 4:09 pm, 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.
>
>>> 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.
>

This is a Xen PV guest.  No SVM/VT-x.

A PV Guest (by it's contract with Xen) cannot create mappings to host
physical addresses it doesn't own.  Xen rejects the attempt, and Linux
is ignoring the failure in this case.  This has been ABI for 25 years.

>From a more practical point of view, because guests can read their own
pagetables, Xen can't swap the requested PTE for safe alternative to
trap the MMIO access, because that violates Linux's model of what's
mapped in this position.

~Andrew