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

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: <85zfd2upub.fsf@amd.com>
Date: Fri, 18 Jul 2025 03:42:36 +0000
From: Nikunj A Dadhania <nikunj@....com>
To: Sean Christopherson <seanjc@...gle.com>, Tom Lendacky
	<thomas.lendacky@....com>
CC: <linux-kernel@...r.kernel.org>, <bp@...en8.de>, <x86@...nel.org>,
	<tglx@...utronix.de>, <mingo@...hat.com>, <dave.hansen@...ux.intel.com>,
	<santosh.shukla@....com>
Subject: Re: [PATCH v2] x86/sev: Improve handling of writes to intercepted
 TSC MSRs

Sean Christopherson <seanjc@...gle.com> writes:

> On Wed, Jul 16, 2025, Tom Lendacky wrote:
>> On 7/16/25 00:53, Nikunj A Dadhania wrote:
>> > From: Sean Christopherson <seanjc@...gle.com>
>> > 
>> > Currently, when a Secure TSC enabled SNP guest attempts to write to the
>> > intercepted GUEST_TSC_FREQ MSR (a read-only MSR), the guest kernel response
>> > incorrectly implies a VMM configuration error, when in fact it is the usual
>> > VMM configuration to intercept writes to read-only MSRs, unless explicitly
>> > documented.
>> > 
>> > Modify the intercepted TSC MSR #VC handling:
>> > * Write to GUEST_TSC_FREQ will generate a #GP instead of terminating the
>> >   guest
>> > * Write to MSR_IA32_TSC will generate a #GP instead of silently ignoring it
>> > 
>> > Add a WARN_ONCE to log the incident, as well-behaved SNP guest kernels
>> > should never attempt to write to these MSRs.
>> > 
>> > However, continue to terminate the guest when reading from intercepted
>> > GUEST_TSC_FREQ MSR with Secure TSC enabled, as intercepted reads indicate
>> > an improper VMM configuration for Secure TSC enabled SNP guests.
>> > 
>> > Signed-off-by: Sean Christopherson <seanjc@...gle.com>
>
> Feel free to drop me as author and just give me a Reported-by or Suggested-by.
> At this point, I ain't doing a whole lot of anything for this patch :-)

Sure

>
>> > +	if (WARN_ON_ONCE(write)) {
>> 
>> Do we want to capture individual WARNs for each MSR? I guess I'm ok with
>> a single WARN for either MSR, but just asking the question.
>
> Or don't WARN at all.  If the caller is doing a bare wrmsrq(), then the kernel
> will WARN in ex_handler_msr().  If the caller is doing wrmsrq_safe(), do we care
> that they're being deliberately weird?

Agree, we can drop the WARN.

Regards,
Nikunj