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: <aKNIQ9b4fixOVSP4@google.com>
Date: Mon, 18 Aug 2025 08:35:31 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Borislav Petkov <bp@...en8.de>
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 Mon, Aug 18, 2025, Borislav Petkov wrote:
> On Mon, Aug 18, 2025 at 07:24:26AM -0700, Sean Christopherson wrote:
> > Most definitely not if the guest owner and host owner are not one and the same.
> > The example use case is where the platform owner is running one of _their_ kernels
> > in a VM, in which case that kernel probably does want to know why the platform
> > reboot.
> 
> Except that can you control who uses that feature? If it ends up being used by
> a VM stack where the guest owner should not know the reboot reason, you've
> lost.

Yeah, but "expose/advertise XYZ to the wrong VM and you've lost" holds true for
so many things.  In all honesty, of the many ways a hypervisor/CSP can screw up,
this one doesn't scare me at all.

> > The same thing that guarantees hardware vendors adhere to specs: the desire to
> > get paid.
> 
> So you're basically saying all HV vendors return -1 for an unimplemented
> register and we should be fine there?

For this type of register, yes, they should.

> > And QEMU did return an error value, 0xffffffff, a.k.a. PCI Master Abort / PCIe
> > Unsupported Request.  I would be amazed if any real world, general purpose VMM
> > did anything else for an MMIO access to an unknown/unsupported range.
> 
> Ok, I guess we will know soon enough. :-)
> 
> > Huh?  Handle a read of all 0xffs as proposed in this patch, and this is unnecessary.
> 
> I don't trust that all HVs will DTRT. But ok, I'll take your word for it.

Heh, I don't I trust hypervisors/VMMs either, but if they don't behave, then we
yell at them and/or send patches.