linux-kernel - Re: [PATCH v15 06/13] x86/sev: Prevent GUEST_TSC_FREQ MSR interception for Secure TSC enabled guests

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: <9d4c903f-424b-41ce-91f7-a8c9bf74c07c@amd.com>
Date: Thu, 2 Jan 2025 10:33:26 +0530
From: "Nikunj A. Dadhania" <nikunj@....com>
To: Borislav Petkov <bp@...en8.de>, thomas.lendacky@....com
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, kvm@...r.kernel.org,
 mingo@...hat.com, tglx@...utronix.de, dave.hansen@...ux.intel.com,
 pgonda@...gle.com, seanjc@...gle.com, pbonzini@...hat.com
Subject: Re: [PATCH v15 06/13] x86/sev: Prevent GUEST_TSC_FREQ MSR
 interception for Secure TSC enabled guests

On 1/1/2025 9:40 PM, Borislav Petkov wrote:
> On Wed, Jan 01, 2025 at 02:14:38PM +0530, Nikunj A. Dadhania wrote:
>> @@ -1437,8 +1471,16 @@ static enum es_result vc_handle_msr(struct ghcb *ghcb, struct es_em_ctxt *ctxt)
>>  	/* Is it a WRMSR? */
>>  	write = ctxt->insn.opcode.bytes[1] == 0x30;
>>  
>> -	if (regs->cx == MSR_SVSM_CAA)
>> +	switch (regs->cx) {
>> +	case MSR_SVSM_CAA:
>>  		return __vc_handle_msr_caa(regs, write);
>> +	case MSR_IA32_TSC:
>> +	case MSR_AMD64_GUEST_TSC_FREQ:
>> +		if (sev_status & MSR_AMD64_SNP_SECURE_TSC)
>> +			return __vc_handle_msr_tsc(regs, write);
> 
> Again: move all the logic inside __vc_handle_msr_tsc().
> 

Boris, I have mentioned in my previous reply why this is incorrect for non-SecureTSC guests with examples and had asked for your confirmation if it is an acceptable behaviour[1] and Tom has also objected to the change of behavior for non-SecureTSC guest[2].

I think we are dragging this a little too far and the implementation[3] that I gave is good without any side effects.

Regards
Nikunj

1: https://lore.kernel.org/all/7a5de2be-4e79-409a-90f2-398815fc59c7@amd.com
2: https://lore.kernel.org/all/1510fe7f-1c10-aea7-75be-37c5c58d6a05@amd.com 
3: https://lore.kernel.org/all/a28dfd0a-c0ab-490f-bc1a-945182d07790@amd.com