linux-kernel - Re: [PATCH v11 19/20] x86/kvmclock: Skip kvmclock when Secure TSC is available

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: <9a218564-b011-4222-187d-cba9e9268e93@amd.com>
Date: Mon, 16 Sep 2024 20:50:20 +0530
From: "Nikunj A. Dadhania" <nikunj@....com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: linux-kernel@...r.kernel.org, thomas.lendacky@....com, bp@...en8.de,
 x86@...nel.org, kvm@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
 dave.hansen@...ux.intel.com, pgonda@...gle.com, pbonzini@...hat.com
Subject: Re: [PATCH v11 19/20] x86/kvmclock: Skip kvmclock when Secure TSC is
 available



On 9/13/2024 11:00 PM, Sean Christopherson wrote:
> On Wed, Jul 31, 2024, Nikunj A Dadhania wrote:
>> For AMD SNP guests with SecureTSC enabled, kvm-clock is being picked up
>> momentarily instead of selecting more stable TSC clocksource.
>>
>> [    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
>> [    0.000001] kvm-clock: using sched offset of 1799357702246960 cycles
>> [    0.001493] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
>> [    0.006289] tsc: Detected 1996.249 MHz processor
>> [    0.305123] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x398cadd9d93, max_idle_ns: 881590552906 ns
>> [    1.045759] clocksource: Switched to clocksource kvm-clock
>> [    1.141326] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x398cadd9d93, max_idle_ns: 881590552906 ns
>> [    1.144634] clocksource: Switched to clocksource tsc
>>
>> When Secure TSC is enabled, skip using the kvmclock. The guest kernel will
>> fallback and use Secure TSC based clocksource.
>>
>> Signed-off-by: Nikunj A Dadhania <nikunj@....com>
>> Tested-by: Peter Gonda <pgonda@...gle.com>
>> ---
>>  arch/x86/kernel/kvmclock.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
>> index 5b2c15214a6b..3d03b4c937b9 100644
>> --- a/arch/x86/kernel/kvmclock.c
>> +++ b/arch/x86/kernel/kvmclock.c
>> @@ -289,7 +289,7 @@ void __init kvmclock_init(void)
>>  {
>>  	u8 flags;
>>  
>> -	if (!kvm_para_available() || !kvmclock)
>> +	if (!kvm_para_available() || !kvmclock || cc_platform_has(CC_ATTR_GUEST_SECURE_TSC))
> 
> I would much prefer we solve the kvmclock vs. TSC fight in a generic way.  Unless
> I've missed something, the fact that the TSC is more trusted in the SNP/TDX world
> is simply what's forcing the issue, but it's not actually the reason why Linux
> should prefer the TSC over kvmclock.  The underlying reason is that platforms that
> support SNP/TDX are guaranteed to have a stable, always running TSC, i.e. that the
> TSC is a superior timesource purely from a functionality perspective.  That it's
> more secure is icing on the cake.

Are you suggesting that whenever the guest is either SNP or TDX, kvmclock should be
disabled assuming that timesource is stable and always running?

Regards
Nikunj