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
| ||
|
Date: Tue, 14 Jun 2022 00:21:16 +0000 From: Ashish Kalra <ashkalra@....com> To: Alper Gun <alpergun@...gle.com> Cc: Brijesh Singh <brijesh.singh@....com>, Ashish.Kalra@....com, x86@...nel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org, linux-coco@...ts.linux.dev, linux-mm@...ck.org, linux-crypto@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>, Tom Lendacky <thomas.lendacky@....com>, "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, Sean Christopherson <seanjc@...gle.com>, Vitaly Kuznetsov <vkuznets@...hat.com>, Wanpeng Li <wanpengli@...cent.com>, Jim Mattson <jmattson@...gle.com>, Andy Lutomirski <luto@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>, Peter Zijlstra <peterz@...radead.org>, Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, David Rientjes <rientjes@...gle.com>, Dov Murik <dovmurik@...ux.ibm.com>, Tobin Feldman-Fitzthum <tobin@....com>, Borislav Petkov <bp@...en8.de>, Michael Roth <michael.roth@....com>, Vlastimil Babka <vbabka@...e.cz>, "Kirill A . Shutemov" <kirill@...temov.name>, Andi Kleen <ak@...ux.intel.com>, tony.luck@...el.com, Marc Orr <marcorr@...gle.com>, sathyanarayanan.kuppuswamy@...ux.intel.com, Pavan Kumar Paluri <papaluri@....com> Subject: Re: [PATCH Part2 v5 23/45] KVM: SVM: Add KVM_SNP_INIT command On 6/13/22 23:33, Alper Gun wrote: > On Mon, Jun 13, 2022 at 4:15 PM Ashish Kalra <ashkalra@....com> wrote: >> Hello Alper, >> >> On 6/13/22 20:58, Alper Gun wrote: >>> static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp) >>>> { >>>> + bool es_active = (argp->id == KVM_SEV_ES_INIT || argp->id == KVM_SEV_SNP_INIT); >>>> struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; >>>> - bool es_active = argp->id == KVM_SEV_ES_INIT; >>>> + bool snp_active = argp->id == KVM_SEV_SNP_INIT; >>>> int asid, ret; >>>> >>>> if (kvm->created_vcpus) >>>> @@ -249,12 +269,22 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp) >>>> return ret; >>>> >>>> sev->es_active = es_active; >>>> + sev->snp_active = snp_active; >>>> asid = sev_asid_new(sev); >>>> if (asid < 0) >>>> goto e_no_asid; >>>> sev->asid = asid; >>>> >>>> - ret = sev_platform_init(&argp->error); >>>> + if (snp_active) { >>>> + ret = verify_snp_init_flags(kvm, argp); >>>> + if (ret) >>>> + goto e_free; >>>> + >>>> + ret = sev_snp_init(&argp->error); >>>> + } else { >>>> + ret = sev_platform_init(&argp->error); >>> After SEV INIT_EX support patches, SEV may be initialized in the platform late. >>> In my tests, if SEV has not been initialized in the platform yet, SNP >>> VMs fail with SEV_DF_FLUSH required error. I tried calling >>> SEV_DF_FLUSH right after the SNP platform init but this time it failed >>> later on the SNP launch update command with SEV_RET_INVALID_PARAM >>> error. Looks like there is another dependency on SEV platform >>> initialization. >>> >>> Calling sev_platform_init for SNP VMs fixes the problem in our tests. >> Trying to get some more context for this issue. >> >> When you say after SEV_INIT_EX support patches, SEV may be initialized >> in the platform late, do you mean sev_pci_init()->sev_snp_init() ... >> sev_platform_init() code path has still not executed on the host BSP ? >> > Correct, INIT_EX requires the file system to be ready and there is a > ccp module param to call it only when needed. > > MODULE_PARM_DESC(psp_init_on_probe, " if true, the PSP will be > initialized on module init. Else the PSP will be initialized on the > first command requiring it"); > > If this module param is false, it won't initialize SEV on the platform > until the first SEV VM. > Ok, that makes sense. So the fix will be to call sev_platform_init() unconditionally here in sev_guest_init(), and both sev_snp_init() and sev_platform_init() are protected from being called again, so there won't be any issues if these functions are invoked again at SNP/SEV VM launch if they have been invoked earlier during module init. Thanks, Ashish
Powered by blists - more mailing lists