linux-kernel - Re: [PATCH v15 04/13] x86/sev: Change TSC MSR behavior 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: <311a718c-916e-44c9-8093-51903f20ff0a@amd.com>
Date: Tue, 10 Dec 2024 22:14:57 +0530
From: Nikunj A Dadhania <nikunj@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, thomas.lendacky@....com, 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 04/13] x86/sev: Change TSC MSR behavior for Secure TSC
 enabled guests

On 12/10/2024 5:13 PM, Borislav Petkov wrote:
> On Tue, Dec 10, 2024 at 10:32:23AM +0530, Nikunj A. Dadhania wrote:
>> Do you also want to terminate the offending guest?
>>
>> ES_UNSUPPORTED return will do that.
> 
> I guess that would be too harsh. I guess a warn and a ES_OK should be fine for
> now.

Yes, that will be better.

>> This is changing the behavior for SEV-ES and SNP guests(non SECURE_TSC), TSC
>> MSR reads are converted to RDTSC. This is a good optimization. But just
>> wanted to bring up the subtle impact.
> 
> That RDTSC happens still in the guest, right? But in its #VC handler. Versus it
> being a HV GHCB protocol call. 

Yes, and the change is working fine, I have verified it.

> I guess this conversion should be a separate
> patch in case there's some issues like the HV intercepting RDTSC... i.e.,
> VMEXIT_RDTSC.

I tried instrumenting code to intercept RDTSC and RDTSCP, KVM does not handle
EXIT_RDTSC and the guest (including non-secure guests) crashes pretty early with
the following in the host kernel log:

kvm_amd: kvm [2153024]: vcpu0, guest rIP: 0xbbea5fc2 svm: unexpected exit reason
0x6e

> We should probably handle that case too and then fallback to the GHCB call. Or
> is there a catch 22 I'm missing here...

Regards,
Nikunj