linux-kernel - Re: [PATCH] x86/sev: Improve handling of writes to intercepted GUEST_TSC

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: <aHUx9ILdUZJHefjZ@google.com>
Date: Mon, 14 Jul 2025 09:36:04 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Tom Lendacky <thomas.lendacky@....com>, Nikunj A Dadhania <nikunj@....com>, 
	linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de, 
	mingo@...hat.com, dave.hansen@...ux.intel.com, santosh.shukla@....com
Subject: Re: [PATCH] x86/sev: Improve handling of writes to intercepted GUEST_TSC_FREQ

On Mon, Jul 14, 2025, Borislav Petkov wrote:
> On Mon, Jul 14, 2025 at 08:17:13AM -0700, Sean Christopherson wrote:
> > The guest cannot dictate VMM behavior.  If the guest side wants to panic, then
> > so be it, panic.  But don't blame the VMM for taking a conservative approach.
> > 
> > If you want to dictate VMM behavior, then the required behavior needs to be
> > explicitly documented in an "official" spec, e.g. the GHCB.
> 
> Ok, so you want to squash the #GP from an attempted write to a MSR into
> a warning because this is how the hypervisor has been handling it already for
> others. Ok, I guess this is established protocol or whatnot.

Or as Tom suggested, return ES_EXCEPTION and let the kernel's normal machinery
WARN on the bad WRMSR.

> Now, why should it panic when a *read* is then attempted?

Because as you note below, the MSR read should succeed.  __vc_handle_secure_tsc_msrs()
is invoked if and only if secure TSC is enabled for the guest.  If RDMSR #VCs,
then the hypervisor has decided to intercept GUEST_TSC_FREQ despite enabling and
advertising secure TSC to the guest.  The guest kernel can either continue on
with degraded security (potentially dangerously so) or panic/terminate.  

> The APM says:
> 
> "Guests that run with Secure TSC enabled may read the GUEST_TSC_FREQ MSR
> (C001_0134h) which returns the effective frequency in MHz of the guest view of
> TSC. This MSR is read-only and attempting to write the MSR or read it when
> outside of a guest with Secure TSC enabled causes a #GP(0) exception."
> 
> So what is the established protocol for reading non-existent MSRs?

Looks like Linux-as-a-guest will request emulation from the hypervisor.  What
the hypervisor does is completely unknown, at least as far as the guest is
concerned.  E.g. the hypervisor could return an error (i.e. "inject" a #GP), or
it could provide garbage (on RDMSR) and drop writres.

> Also, if secure TSC is enabled, that MSR read should succeed.
> 
> The original text in the patch:
> 
> "Only terminate the guest when reading from intercepted GUEST_TSC_FREQ MSR
> with Secure TSC enabled, as this indicates an unexpected hypervisor
> configuration."
> 
> doesn't make too much sense to me.
> 
> Maybe you need to explain things in detail as virt and I don't understand each
> other too much yet.
> 
> :-)
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette