| Message ID | 20241107232457.4059785-10-dionnaglaze@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v5,01/10] KVM: SVM: Fix gctx page leak on invalid inputs | expand |
On 11/7/24 17:24, Dionna Glaze wrote: > Guest context pages should be near 1-to-1 with allocated ASIDs. With the > GCTX API, the ccp driver is better able to associate guest context pages > with the ASID that is/will be bound to it. > > This is important to the firmware hotloading implementation to not > corrupt any running VM's guest context page before userspace commits a > new firmware. > > CC: Sean Christopherson <seanjc@google.com> > CC: Paolo Bonzini <pbonzini@redhat.com> > CC: Thomas Gleixner <tglx@linutronix.de> > CC: Ingo Molnar <mingo@redhat.com> > CC: Borislav Petkov <bp@alien8.de> > CC: Dave Hansen <dave.hansen@linux.intel.com> > CC: Ashish Kalra <ashish.kalra@amd.com> > CC: Tom Lendacky <thomas.lendacky@amd.com> > CC: John Allen <john.allen@amd.com> > CC: Herbert Xu <herbert@gondor.apana.org.au> > CC: "David S. Miller" <davem@davemloft.net> > CC: Michael Roth <michael.roth@amd.com> > CC: Luis Chamberlain <mcgrof@kernel.org> > CC: Russ Weight <russ.weight@linux.dev> > CC: Danilo Krummrich <dakr@redhat.com> > CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > CC: "Rafael J. Wysocki" <rafael@kernel.org> > CC: Tianfei zhang <tianfei.zhang@intel.com> > CC: Alexey Kardashevskiy <aik@amd.com> > > Signed-off-by: Dionna Glaze <dionnaglaze@google.com> > --- > arch/x86/kvm/svm/sev.c | 74 ++++++++++++------------------------------ > 1 file changed, 20 insertions(+), 54 deletions(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index cea41b8cdabe4..d7cef84750b33 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -89,7 +89,7 @@ static unsigned int nr_asids; > static unsigned long *sev_asid_bitmap; > static unsigned long *sev_reclaim_asid_bitmap; > > -static int snp_decommission_context(struct kvm *kvm); > +static int kvm_decommission_snp_context(struct kvm *kvm); Why the name change? It seems like it just makes the patch a bit harder to follow since there are two things going on. Thanks, Tom > > struct enc_region { > struct list_head list; > @@ -2168,51 +2168,12 @@ int sev_dev_get_attr(u32 group, u64 attr, u64 *val) > } > } > > -/* > - * The guest context contains all the information, keys and metadata > - * associated with the guest that the firmware tracks to implement SEV > - * and SNP features. The firmware stores the guest context in hypervisor > - * provide page via the SNP_GCTX_CREATE command. > - */ > -static void *snp_context_create(struct kvm *kvm, struct kvm_sev_cmd *argp) > -{ > - struct sev_data_snp_addr data = {}; > - void *context; > - int rc; > - > - /* Allocate memory for context page */ > - context = snp_alloc_firmware_page(GFP_KERNEL_ACCOUNT); > - if (!context) > - return ERR_PTR(-ENOMEM); > - > - data.address = __psp_pa(context); > - rc = __sev_issue_cmd(argp->sev_fd, SEV_CMD_SNP_GCTX_CREATE, &data, &argp->error); > - if (rc) { > - pr_warn("Failed to create SEV-SNP context, rc %d fw_error %d", > - rc, argp->error); > - snp_free_firmware_page(context); > - return ERR_PTR(rc); > - } > - > - return context; > -} > - > -static int snp_bind_asid(struct kvm *kvm, int *error) > -{ > - struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > - struct sev_data_snp_activate data = {0}; > - > - data.gctx_paddr = __psp_pa(sev->snp_context); > - data.asid = sev_get_asid(kvm); > - return sev_issue_cmd(kvm, SEV_CMD_SNP_ACTIVATE, &data, error); > -} > - > static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) > { > struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > struct sev_data_snp_launch_start start = {0}; > struct kvm_sev_snp_launch_start params; > - int rc; > + int rc, asid; > > if (!sev_snp_guest(kvm)) > return -ENOTTY; > @@ -2238,14 +2199,19 @@ static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) > if (params.policy & SNP_POLICY_MASK_SINGLE_SOCKET) > return -EINVAL; > > - sev->snp_context = snp_context_create(kvm, argp); > + rc = sev_check_external_user(argp->sev_fd); > + if (rc) > + return rc; > + > + asid = sev_get_asid(kvm); > + sev->snp_context = sev_snp_create_context(asid, &argp->error); > if (IS_ERR(sev->snp_context)) > return PTR_ERR(sev->snp_context); > > start.gctx_paddr = __psp_pa(sev->snp_context); > start.policy = params.policy; > memcpy(start.gosvw, params.gosvw, sizeof(params.gosvw)); > - rc = __sev_issue_cmd(argp->sev_fd, SEV_CMD_SNP_LAUNCH_START, &start, &argp->error); > + rc = sev_do_cmd(SEV_CMD_SNP_LAUNCH_START, &start, &argp->error); > if (rc) { > pr_debug("%s: SEV_CMD_SNP_LAUNCH_START firmware command failed, rc %d\n", > __func__, rc); > @@ -2253,7 +2219,7 @@ static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) > } > > sev->fd = argp->sev_fd; > - rc = snp_bind_asid(kvm, &argp->error); > + rc = sev_snp_activate_asid(asid, &argp->error); > if (rc) { > pr_debug("%s: Failed to bind ASID to SEV-SNP context, rc %d\n", > __func__, rc); > @@ -2263,7 +2229,7 @@ static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) > return 0; > > e_free_context: > - snp_decommission_context(kvm); > + kvm_decommission_snp_context(kvm); > > return rc; > } > @@ -2874,26 +2840,26 @@ int sev_vm_copy_enc_context_from(struct kvm *kvm, unsigned int source_fd) > return ret; > } > > -static int snp_decommission_context(struct kvm *kvm) > +static int kvm_decommission_snp_context(struct kvm *kvm) > { > struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > - struct sev_data_snp_addr data = {}; > - int ret; > + int ret, error; > > /* If context is not created then do nothing */ > if (!sev->snp_context) > return 0; > > - /* Do the decommision, which will unbind the ASID from the SNP context */ > - data.address = __sme_pa(sev->snp_context); > + /* > + * Do the decommision, which will unbind the ASID from the SNP context > + * and free the context page. > + */ > down_write(&sev_deactivate_lock); > - ret = sev_do_cmd(SEV_CMD_SNP_DECOMMISSION, &data, NULL); > + ret = sev_snp_guest_decommission(sev->asid, &error); > up_write(&sev_deactivate_lock); > > - if (WARN_ONCE(ret, "Failed to release guest context, ret %d", ret)) > + if (WARN_ONCE(ret, "Failed to release guest context, ret %d fw err %d", ret, error)) > return ret; > > - snp_free_firmware_page(sev->snp_context); > sev->snp_context = NULL; > > return 0; > @@ -2947,7 +2913,7 @@ void sev_vm_destroy(struct kvm *kvm) > * Decomission handles unbinding of the ASID. If it fails for > * some unexpected reason, just leak the ASID. > */ > - if (snp_decommission_context(kvm)) > + if (kvm_decommission_snp_context(kvm)) > return; > } else { > sev_unbind_asid(kvm, sev->handle);
> > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > > index cea41b8cdabe4..d7cef84750b33 100644 > > --- a/arch/x86/kvm/svm/sev.c > > +++ b/arch/x86/kvm/svm/sev.c > > @@ -89,7 +89,7 @@ static unsigned int nr_asids; > > static unsigned long *sev_asid_bitmap; > > static unsigned long *sev_reclaim_asid_bitmap; > > > > -static int snp_decommission_context(struct kvm *kvm); > > +static int kvm_decommission_snp_context(struct kvm *kvm); > > Why the name change? It seems like it just makes the patch a bit harder > to follow since there are two things going on. > KVM and ccp both seem to like to name their functions starting with sev_ or snp_, and it's particularly hard to determine provenance. snp_decommision_context and sev_snp_guest_decommission... which is from where? It's weird to me. > Thanks, > Tom >
On 11/12/24 13:33, Dionna Amalie Glaze wrote: >>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c >>> index cea41b8cdabe4..d7cef84750b33 100644 >>> --- a/arch/x86/kvm/svm/sev.c >>> +++ b/arch/x86/kvm/svm/sev.c >>> @@ -89,7 +89,7 @@ static unsigned int nr_asids; >>> static unsigned long *sev_asid_bitmap; >>> static unsigned long *sev_reclaim_asid_bitmap; >>> >>> -static int snp_decommission_context(struct kvm *kvm); >>> +static int kvm_decommission_snp_context(struct kvm *kvm); >> >> Why the name change? It seems like it just makes the patch a bit harder >> to follow since there are two things going on. >> > > KVM and ccp both seem to like to name their functions starting with > sev_ or snp_, and it's particularly hard to determine provenance. > > snp_decommision_context and sev_snp_guest_decommission... which is > from where? It's weird to me. I guess I don't see the problem, a quick git grep -w of the name will show you where each is. Its a static function in the file, so if anything just changing/shortening the name to decommission_snp_context() would be better (especially since nothing in the svm directory should have a name that starts with kvm_). Thanks, Tom > >> Thanks, >> Tom >> > >
On Tue, Nov 12, 2024, Tom Lendacky wrote: > On 11/12/24 13:33, Dionna Amalie Glaze wrote: > >>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > >>> index cea41b8cdabe4..d7cef84750b33 100644 > >>> --- a/arch/x86/kvm/svm/sev.c > >>> +++ b/arch/x86/kvm/svm/sev.c > >>> @@ -89,7 +89,7 @@ static unsigned int nr_asids; > >>> static unsigned long *sev_asid_bitmap; > >>> static unsigned long *sev_reclaim_asid_bitmap; > >>> > >>> -static int snp_decommission_context(struct kvm *kvm); > >>> +static int kvm_decommission_snp_context(struct kvm *kvm); > >> > >> Why the name change? It seems like it just makes the patch a bit harder > >> to follow since there are two things going on. > >> > > > > KVM and ccp both seem to like to name their functions starting with > > sev_ or snp_, and it's particularly hard to determine provenance. > > > > snp_decommision_context and sev_snp_guest_decommission... which is > > from where? It's weird to me. > > I guess I don't see the problem, a quick git grep -w of the name will > show you where each is. Its a static function in the file, so if > anything just changing/shortening the name to decommission_snp_context() Eh, that creates just as many problems as it solves, because it mucks up the namespace and leads to discontinuity between the decommission helper and things like snp_launch_update_vmsa() and snp_launch_finish(). I agree that there isn't a strong need to fixup static symbols. That said, I do think drivers/crypto/ccp/sev-dev.c in particular needs a different namespace, and needs to use it consistently, to make it somewhat obvious that it's (almost) all about the PSP/ASP. But IMO, an even bigger mess in that area is the lack of consistency in the APIs themselves. E.g. this code where KVM uses sev_do_cmd() directly for SNP, but bounces through a wrapper for !SNP. Eww. wbinvd_on_all_cpus(); if (sev_snp_enabled) ret = sev_do_cmd(SEV_CMD_SNP_DF_FLUSH, NULL, &error); else ret = sev_guest_df_flush(&error); up_write(&sev_deactivate_lock); And then KVM has snp_page_reclaim(), but the PSP/ASP driver has snp_reclaim_pages(). So if we want to start renaming things, I vote to go a step further and clean up the APIs, e.g. with a goal of eliminating sev_do_cmd(), and possibly of making the majority of the PSP-defined structures in include/linux/psp-sev.h "private" to the PSP/ASP driver. > would be better (especially since nothing in the svm directory should > have a name that starts with kvm_). +1 to not using "kvm_". KVM often uses "kvm_" to differentiate globally visible symbols from local (static) symbols. I.e. prepending "kvm_" just trades one confusing name for another.
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index cea41b8cdabe4..d7cef84750b33 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -89,7 +89,7 @@ static unsigned int nr_asids; static unsigned long *sev_asid_bitmap; static unsigned long *sev_reclaim_asid_bitmap; -static int snp_decommission_context(struct kvm *kvm); +static int kvm_decommission_snp_context(struct kvm *kvm); struct enc_region { struct list_head list; @@ -2168,51 +2168,12 @@ int sev_dev_get_attr(u32 group, u64 attr, u64 *val) } } -/* - * The guest context contains all the information, keys and metadata - * associated with the guest that the firmware tracks to implement SEV - * and SNP features. The firmware stores the guest context in hypervisor - * provide page via the SNP_GCTX_CREATE command. - */ -static void *snp_context_create(struct kvm *kvm, struct kvm_sev_cmd *argp) -{ - struct sev_data_snp_addr data = {}; - void *context; - int rc; - - /* Allocate memory for context page */ - context = snp_alloc_firmware_page(GFP_KERNEL_ACCOUNT); - if (!context) - return ERR_PTR(-ENOMEM); - - data.address = __psp_pa(context); - rc = __sev_issue_cmd(argp->sev_fd, SEV_CMD_SNP_GCTX_CREATE, &data, &argp->error); - if (rc) { - pr_warn("Failed to create SEV-SNP context, rc %d fw_error %d", - rc, argp->error); - snp_free_firmware_page(context); - return ERR_PTR(rc); - } - - return context; -} - -static int snp_bind_asid(struct kvm *kvm, int *error) -{ - struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; - struct sev_data_snp_activate data = {0}; - - data.gctx_paddr = __psp_pa(sev->snp_context); - data.asid = sev_get_asid(kvm); - return sev_issue_cmd(kvm, SEV_CMD_SNP_ACTIVATE, &data, error); -} - static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) { struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; struct sev_data_snp_launch_start start = {0}; struct kvm_sev_snp_launch_start params; - int rc; + int rc, asid; if (!sev_snp_guest(kvm)) return -ENOTTY; @@ -2238,14 +2199,19 @@ static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) if (params.policy & SNP_POLICY_MASK_SINGLE_SOCKET) return -EINVAL; - sev->snp_context = snp_context_create(kvm, argp); + rc = sev_check_external_user(argp->sev_fd); + if (rc) + return rc; + + asid = sev_get_asid(kvm); + sev->snp_context = sev_snp_create_context(asid, &argp->error); if (IS_ERR(sev->snp_context)) return PTR_ERR(sev->snp_context); start.gctx_paddr = __psp_pa(sev->snp_context); start.policy = params.policy; memcpy(start.gosvw, params.gosvw, sizeof(params.gosvw)); - rc = __sev_issue_cmd(argp->sev_fd, SEV_CMD_SNP_LAUNCH_START, &start, &argp->error); + rc = sev_do_cmd(SEV_CMD_SNP_LAUNCH_START, &start, &argp->error); if (rc) { pr_debug("%s: SEV_CMD_SNP_LAUNCH_START firmware command failed, rc %d\n", __func__, rc); @@ -2253,7 +2219,7 @@ static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) } sev->fd = argp->sev_fd; - rc = snp_bind_asid(kvm, &argp->error); + rc = sev_snp_activate_asid(asid, &argp->error); if (rc) { pr_debug("%s: Failed to bind ASID to SEV-SNP context, rc %d\n", __func__, rc); @@ -2263,7 +2229,7 @@ static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) return 0; e_free_context: - snp_decommission_context(kvm); + kvm_decommission_snp_context(kvm); return rc; } @@ -2874,26 +2840,26 @@ int sev_vm_copy_enc_context_from(struct kvm *kvm, unsigned int source_fd) return ret; } -static int snp_decommission_context(struct kvm *kvm) +static int kvm_decommission_snp_context(struct kvm *kvm) { struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; - struct sev_data_snp_addr data = {}; - int ret; + int ret, error; /* If context is not created then do nothing */ if (!sev->snp_context) return 0; - /* Do the decommision, which will unbind the ASID from the SNP context */ - data.address = __sme_pa(sev->snp_context); + /* + * Do the decommision, which will unbind the ASID from the SNP context + * and free the context page. + */ down_write(&sev_deactivate_lock); - ret = sev_do_cmd(SEV_CMD_SNP_DECOMMISSION, &data, NULL); + ret = sev_snp_guest_decommission(sev->asid, &error); up_write(&sev_deactivate_lock); - if (WARN_ONCE(ret, "Failed to release guest context, ret %d", ret)) + if (WARN_ONCE(ret, "Failed to release guest context, ret %d fw err %d", ret, error)) return ret; - snp_free_firmware_page(sev->snp_context); sev->snp_context = NULL; return 0; @@ -2947,7 +2913,7 @@ void sev_vm_destroy(struct kvm *kvm) * Decomission handles unbinding of the ASID. If it fails for * some unexpected reason, just leak the ASID. */ - if (snp_decommission_context(kvm)) + if (kvm_decommission_snp_context(kvm)) return; } else { sev_unbind_asid(kvm, sev->handle);
Guest context pages should be near 1-to-1 with allocated ASIDs. With the GCTX API, the ccp driver is better able to associate guest context pages with the ASID that is/will be bound to it. This is important to the firmware hotloading implementation to not corrupt any running VM's guest context page before userspace commits a new firmware. CC: Sean Christopherson <seanjc@google.com> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: Borislav Petkov <bp@alien8.de> CC: Dave Hansen <dave.hansen@linux.intel.com> CC: Ashish Kalra <ashish.kalra@amd.com> CC: Tom Lendacky <thomas.lendacky@amd.com> CC: John Allen <john.allen@amd.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: "David S. Miller" <davem@davemloft.net> CC: Michael Roth <michael.roth@amd.com> CC: Luis Chamberlain <mcgrof@kernel.org> CC: Russ Weight <russ.weight@linux.dev> CC: Danilo Krummrich <dakr@redhat.com> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: "Rafael J. Wysocki" <rafael@kernel.org> CC: Tianfei zhang <tianfei.zhang@intel.com> CC: Alexey Kardashevskiy <aik@amd.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> --- arch/x86/kvm/svm/sev.c | 74 ++++++++++++------------------------------ 1 file changed, 20 insertions(+), 54 deletions(-)