Re: [PATCH v15 07/13] x86/sev: Mark Secure TSC as reliable clocksource

[Nikunj A Dadhania]

On 12/12/2024 2:02 AM, Borislav Petkov wrote:
> On Tue, Dec 03, 2024 at 02:30:39PM +0530, Nikunj A Dadhania wrote:
>> diff --git a/arch/x86/mm/mem_encrypt_amd.c b/arch/x86/mm/mem_encrypt_amd.c
>> index 774f9677458f..fa0bc52ef707 100644
>> --- a/arch/x86/mm/mem_encrypt_amd.c
>> +++ b/arch/x86/mm/mem_encrypt_amd.c
>> @@ -541,6 +541,10 @@ void __init sme_early_init(void)
>>  	 * kernel mapped.
>>  	 */
>>  	snp_update_svsm_ca();
>> +
>> +	/* Mark the TSC as reliable when Secure TSC is enabled */
>> +	if (sev_status & MSR_AMD64_SNP_SECURE_TSC)
>> +		setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
> 
> What happens if someone writes MSR 0x10 on some CPU and thus makes the TSCs on
> the host unsynchronized and that CPU runs a SecureTSC guest?
> 
> That guest would use RDTSC and get wrong values and turn the guest into
> a mess, right?

No, SecureTSC guest keeps on ticking forward even when the HV has written to 
MSR 0x10 on the CPU where the SecureTSC guest is running.

I performed following experiment to confirm the behavior:

1) Started the SecureTSC guest pinned to CPU10

host $ taskset -c 10 ./bootg_sectsc.sh

2) Read TSC MSR on guest

guest $ sudo rdmsr 0x10
8005a5b2d634c

3) Set TSC MSR to 0 on CPU10 on host.

host $ sudo wrmsr -p 10 0x10 0
host $ sudo rdmsr -p 10 0x10
4846ad0

4) Read TSC MSR on guest again

guest $ sudo rdmsr 0x10
8005d18a7144f

Regards,
Nikunj