linux-kernel - Re: [PATCH 00/10] KVM: SVM: Attempt to cleanup SEV

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <81949e94-9b7f-0b04-d673-cbc16fc646a5@amd.com>
Date: Mon, 24 Feb 2025 18:02:29 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: Sean Christopherson <seanjc@...gle.com>,
 Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Naveen N Rao <naveen@...nel.org>, Kim Phillips <kim.phillips@....com>,
 Alexey Kardashevskiy <aik@....com>
Subject: Re: [PATCH 00/10] KVM: SVM: Attempt to cleanup SEV_FEATURES

On 2/20/25 16:51, Tom Lendacky wrote:
> On 2/18/25 19:26, Sean Christopherson wrote:
>> This is a hastily thrown together series, barely above RFC, to try and
>> address the worst of the issues that arise with guest controlled SEV
>> features (thanks AP creation)[1].
>>
>> In addition to the initial flaws with DebugSwap, I came across a variety
>> of issues when trying to figure out how best to handle SEV features in
>> general.  E.g. AFAICT, KVM doesn't guard against userspace manually making
>> a vCPU RUNNABLE after it has been DESTROYED (or after a failed CREATE).
>>
>> This is essentially compile-tested only, as I don't have easy access to a
>> system with SNP enabled.  I ran the SEV-ES selftests, but that's not much
>> in the way of test coverage.
>>
>> AMD folks, I would greatly appreciate reviews, testing, and most importantly,
>> confirmation that all of this actually works the way I think it does.
> 
> A quick test of a 64 vCPU SNP guest booted successfully, so that's a
> good start. I'll take a closer look at these patches over the next few days.

Everything looks good. I'm going to try messing around with the
DebugSwap feature bit just to try some of those odd cases and make sure
everything does what it is supposed to. Should have results in a day or two.

Thanks,
Tom

> 
> Thanks,
> Tom
> 
>>
>> [1] https://lore.kernel.org/all/Z7TSef290IQxQhT2@google.com
>>
>> Sean Christopherson (10):
>>   KVM: SVM: Save host DR masks but NOT DRs on CPUs with DebugSwap
>>   KVM: SVM: Don't rely on DebugSwap to restore host DR0..DR3
>>   KVM: SVM: Terminate the VM if a SEV-ES+ guest is run with an invalid
>>     VMSA
>>   KVM: SVM: Don't change target vCPU state on AP Creation VMGEXIT error
>>   KVM: SVM: Require AP's "requested" SEV_FEATURES to match KVM's view
>>   KVM: SVM: Simplify request+kick logic in SNP AP Creation handling
>>   KVM: SVM: Use guard(mutex) to simplify SNP AP Creation error handling
>>   KVM: SVM: Mark VMCB dirty before processing incoming snp_vmsa_gpa
>>   KVM: SVM: Use guard(mutex) to simplify SNP vCPU state updates
>>   KVM: SVM: Invalidate "next" SNP VMSA GPA even on failure
>>
>>  arch/x86/kvm/svm/sev.c | 218 +++++++++++++++++++----------------------
>>  arch/x86/kvm/svm/svm.c |   7 +-
>>  arch/x86/kvm/svm/svm.h |   2 +-
>>  3 files changed, 106 insertions(+), 121 deletions(-)
>>
>>
>> base-commit: fed48e2967f402f561d80075a20c5c9e16866e53