linux-kernel - Re: [PATCH] x86/CPU/AMD: Ignore invalid reset reason value

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: <20250725065009.GAaIMpIVgAKi0kMBVv@renoirsky.local>
Date: Fri, 25 Jul 2025 08:50:09 +0200
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Mario Limonciello <mario.limonciello@....com>,
	Yazen Ghannam <yazen.ghannam@....com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Libing He <libhe@...hat.com>,
	David Arcari <darcari@...hat.com>
Subject: Re: [PATCH] x86/CPU/AMD: Ignore invalid reset reason value

On Thu, Jul 24, 2025 at 02:32:41PM -0700, Sean Christopherson wrote:
> Not necessarily.  There are a variety of use cases for doing nearly-full passthrough
> of bare metal state into a VM, e.g. to deprivilege the "main" OS, interpose and/or
> isolate select resources, etc.  I don't think it's too far fetched to imagine one
> or more such use cases exposing this range of MMIO to the guest _and_ also setting
> the HYPERVISOR bit in CPUID.

What would be that use case?

To tell the guest why the hypervisor rebooted?

Sounds weird to me but virt does weird things sometimes. :-P

> But whether or not there's a legitimate use case is beside the point.  I'm not
> arguing this is at all useful for VMs.  I'm arguing _against_ splattering
> X86_FEATURE_HYPERVISOR checks all over the place just because an error was first
> (or only) observed while running in a VM.

We use X86_FEATURE_HYPERVISOR to gate purely-hw-only features behind it.
Because they don't make any sense for guests. Just like this one.

And even if this one makes sense for some virt scenario, we want those
folks to *actually* explain why removing the HV check for that feature
makes sense. And why the kernel needs to support it.

Just like loading microcode in a guest, for example. There's a reason we
don't do that. And when some day, someone appears and wants to do that,
I would like there to be an explicit patch removing that HV check in the
loader and explaining *why* it is doing so.

And until that day, that feature is hw-only. Just like this one.

And yeah, I know you don't like X86_FEATURE_HYPERVISOR but I would like
to save some of my sanity when looking at a bug report which says that
the reboot reason reporting is talking crap, only to find out that a HV
underneath is doing something silly, muddying up the waters.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette