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: <20250714161639.GLaHUtZwleS3COfxxX@fat_crate.local>
Date: Mon, 14 Jul 2025 18:16:39 +0200
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
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 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.

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

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?

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