From: Dov Murik <dovmurik@linux.ibm.com> To: Brijesh Singh <brijesh.singh@amd.com>, qemu-devel@nongnu.org Cc: "Connor Kuehl" <ckuehl@redhat.com>, "Philippe Mathieu-Daudé" <philmd@redhat.com>, "Michael S . Tsirkin" <mst@redhat.com>, "James Bottomley" <jejb@linux.ibm.com>, "Dr . David Alan Gilbert" <dgilbert@redhat.com>, "Tom Lendacky" <thomas.lendacky@amd.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "David Gibson" <david@gibson.dropbear.id.au>, "Daniel P. Berrangé" <berrange@redhat.com>, kvm@vger.kernel.org, "Michael Roth" <michael.roth@amd.com>, "Eduardo Habkost" <ehabkost@redhat.com>, "Dov Murik" <dovmurik@linux.ibm.com> Subject: Re: [RFC PATCH 5/6] i386/sev: add support to encrypt BIOS when SEV-SNP is enabled Date: Mon, 19 Jul 2021 16:00:55 +0300 [thread overview] Message-ID: <0ab7b398-238e-38c5-aed1-fd39fd9c7f7c@linux.ibm.com> (raw) In-Reply-To: <20210709215550.32496-6-brijesh.singh@amd.com> On 10/07/2021 0:55, Brijesh Singh wrote: > The KVM_SEV_SNP_LAUNCH_UPDATE command is used for encrypting the bios > image used for booting the SEV-SNP guest. > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > --- > target/i386/sev.c | 33 ++++++++++++++++++++++++++++++++- > target/i386/trace-events | 1 + > 2 files changed, 33 insertions(+), 1 deletion(-) > > diff --git a/target/i386/sev.c b/target/i386/sev.c > index 259408a8f1..41dcb084d1 100644 > --- a/target/i386/sev.c > +++ b/target/i386/sev.c > @@ -883,6 +883,30 @@ out: > return ret; > } > > +static int > +sev_snp_launch_update(SevGuestState *sev, uint8_t *addr, uint64_t len, int type) This seems similar to the SEV LAUNCH_UPDATE_DATA API (with the added `type` argument). In SEV API these are the limitations (from the SEV API document): * PADDR - System physical address of the data to be encrypted. Must be 16 B aligned. * LENGTH - Length of the data to be encrypted. Must be a multiple of 16 B. But in SNP_LAUNCH_UPDATE it is my understanding that addr must be page aligned (4KB) and length must be in whole pages (because the underlying types are PAGE_TYPE_NORMAL, PAGE_TYPE_ZERO, ...). So what happens if we call sev_encrypt_flash with a non-page-aligned addr / length? Or maybe I misunderstood the SNP ABI document? -Dov > +{ > + int ret, fw_error; > + struct kvm_sev_snp_launch_update update = {}; > + > + if (!addr || !len) { > + return 1; > + } > + > + update.uaddr = (__u64)(unsigned long)addr; > + update.len = len; > + update.page_type = type; > + trace_kvm_sev_snp_launch_update(addr, len, type); > + ret = sev_ioctl(sev->sev_fd, KVM_SEV_SNP_LAUNCH_UPDATE, > + &update, &fw_error); > + if (ret) { > + error_report("%s: SNP_LAUNCH_UPDATE ret=%d fw_error=%d '%s'", > + __func__, ret, fw_error, fw_error_to_str(fw_error)); > + } > + > + return ret; > +} > + > static int > sev_launch_update_data(SevGuestState *sev, uint8_t *addr, uint64_t len) > { > @@ -1161,7 +1185,14 @@ sev_encrypt_flash(uint8_t *ptr, uint64_t len, Error **errp) > > /* if SEV is in update state then encrypt the data else do nothing */ > if (sev_check_state(sev_guest, SEV_STATE_LAUNCH_UPDATE)) { > - int ret = sev_launch_update_data(sev_guest, ptr, len); > + int ret; > + > + if (sev_snp_enabled()) { > + ret = sev_snp_launch_update(sev_guest, ptr, len, > + KVM_SEV_SNP_PAGE_TYPE_NORMAL); > + } else { > + ret = sev_launch_update_data(sev_guest, ptr, len); > + } > if (ret < 0) { > error_setg(errp, "failed to encrypt pflash rom"); > return ret; > diff --git a/target/i386/trace-events b/target/i386/trace-events > index 18cc14b956..0c2d250206 100644 > --- a/target/i386/trace-events > +++ b/target/i386/trace-events > @@ -12,3 +12,4 @@ kvm_sev_launch_finish(void) "" > kvm_sev_launch_secret(uint64_t hpa, uint64_t hva, uint64_t secret, int len) "hpa 0x%" PRIx64 " hva 0x%" PRIx64 " data 0x%" PRIx64 " len %d" > kvm_sev_attestation_report(const char *mnonce, const char *data) "mnonce %s data %s" > kvm_sev_snp_launch_start(uint64_t policy) "policy 0x%" PRIx64 > +kvm_sev_snp_launch_update(void *addr, uint64_t len, int type) "addr %p len 0x%" PRIx64 " type %d" >
WARNING: multiple messages have this Message-ID (diff)
From: Dov Murik <dovmurik@linux.ibm.com> To: Brijesh Singh <brijesh.singh@amd.com>, qemu-devel@nongnu.org Cc: "Tom Lendacky" <thomas.lendacky@amd.com>, "Daniel P. Berrangé" <berrange@redhat.com>, "Eduardo Habkost" <ehabkost@redhat.com>, kvm@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>, "Connor Kuehl" <ckuehl@redhat.com>, "Michael Roth" <michael.roth@amd.com>, "James Bottomley" <jejb@linux.ibm.com>, "Dr . David Alan Gilbert" <dgilbert@redhat.com>, "Dov Murik" <dovmurik@linux.ibm.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Philippe Mathieu-Daudé" <philmd@redhat.com>, "David Gibson" <david@gibson.dropbear.id.au> Subject: Re: [RFC PATCH 5/6] i386/sev: add support to encrypt BIOS when SEV-SNP is enabled Date: Mon, 19 Jul 2021 16:00:55 +0300 [thread overview] Message-ID: <0ab7b398-238e-38c5-aed1-fd39fd9c7f7c@linux.ibm.com> (raw) In-Reply-To: <20210709215550.32496-6-brijesh.singh@amd.com> On 10/07/2021 0:55, Brijesh Singh wrote: > The KVM_SEV_SNP_LAUNCH_UPDATE command is used for encrypting the bios > image used for booting the SEV-SNP guest. > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > --- > target/i386/sev.c | 33 ++++++++++++++++++++++++++++++++- > target/i386/trace-events | 1 + > 2 files changed, 33 insertions(+), 1 deletion(-) > > diff --git a/target/i386/sev.c b/target/i386/sev.c > index 259408a8f1..41dcb084d1 100644 > --- a/target/i386/sev.c > +++ b/target/i386/sev.c > @@ -883,6 +883,30 @@ out: > return ret; > } > > +static int > +sev_snp_launch_update(SevGuestState *sev, uint8_t *addr, uint64_t len, int type) This seems similar to the SEV LAUNCH_UPDATE_DATA API (with the added `type` argument). In SEV API these are the limitations (from the SEV API document): * PADDR - System physical address of the data to be encrypted. Must be 16 B aligned. * LENGTH - Length of the data to be encrypted. Must be a multiple of 16 B. But in SNP_LAUNCH_UPDATE it is my understanding that addr must be page aligned (4KB) and length must be in whole pages (because the underlying types are PAGE_TYPE_NORMAL, PAGE_TYPE_ZERO, ...). So what happens if we call sev_encrypt_flash with a non-page-aligned addr / length? Or maybe I misunderstood the SNP ABI document? -Dov > +{ > + int ret, fw_error; > + struct kvm_sev_snp_launch_update update = {}; > + > + if (!addr || !len) { > + return 1; > + } > + > + update.uaddr = (__u64)(unsigned long)addr; > + update.len = len; > + update.page_type = type; > + trace_kvm_sev_snp_launch_update(addr, len, type); > + ret = sev_ioctl(sev->sev_fd, KVM_SEV_SNP_LAUNCH_UPDATE, > + &update, &fw_error); > + if (ret) { > + error_report("%s: SNP_LAUNCH_UPDATE ret=%d fw_error=%d '%s'", > + __func__, ret, fw_error, fw_error_to_str(fw_error)); > + } > + > + return ret; > +} > + > static int > sev_launch_update_data(SevGuestState *sev, uint8_t *addr, uint64_t len) > { > @@ -1161,7 +1185,14 @@ sev_encrypt_flash(uint8_t *ptr, uint64_t len, Error **errp) > > /* if SEV is in update state then encrypt the data else do nothing */ > if (sev_check_state(sev_guest, SEV_STATE_LAUNCH_UPDATE)) { > - int ret = sev_launch_update_data(sev_guest, ptr, len); > + int ret; > + > + if (sev_snp_enabled()) { > + ret = sev_snp_launch_update(sev_guest, ptr, len, > + KVM_SEV_SNP_PAGE_TYPE_NORMAL); > + } else { > + ret = sev_launch_update_data(sev_guest, ptr, len); > + } > if (ret < 0) { > error_setg(errp, "failed to encrypt pflash rom"); > return ret; > diff --git a/target/i386/trace-events b/target/i386/trace-events > index 18cc14b956..0c2d250206 100644 > --- a/target/i386/trace-events > +++ b/target/i386/trace-events > @@ -12,3 +12,4 @@ kvm_sev_launch_finish(void) "" > kvm_sev_launch_secret(uint64_t hpa, uint64_t hva, uint64_t secret, int len) "hpa 0x%" PRIx64 " hva 0x%" PRIx64 " data 0x%" PRIx64 " len %d" > kvm_sev_attestation_report(const char *mnonce, const char *data) "mnonce %s data %s" > kvm_sev_snp_launch_start(uint64_t policy) "policy 0x%" PRIx64 > +kvm_sev_snp_launch_update(void *addr, uint64_t len, int type) "addr %p len 0x%" PRIx64 " type %d" >
next prev parent reply other threads:[~2021-07-19 13:01 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-09 21:55 [RFC PATCH 0/6] Add AMD Secure Nested Paging (SEV-SNP) support Brijesh Singh 2021-07-09 21:55 ` [RFC PATCH 1/6] linux-header: add the SNP specific command Brijesh Singh 2021-07-10 20:32 ` Michael S. Tsirkin 2021-07-10 20:32 ` Michael S. Tsirkin 2021-07-12 15:48 ` Brijesh Singh 2021-07-19 11:35 ` Dov Murik 2021-07-19 11:35 ` Dov Murik 2021-07-19 14:40 ` Brijesh Singh 2021-07-09 21:55 ` [RFC PATCH 2/6] i386/sev: extend sev-guest property to include SEV-SNP Brijesh Singh 2021-07-12 6:09 ` Dov Murik 2021-07-12 6:09 ` Dov Murik 2021-07-12 14:34 ` Dr. David Alan Gilbert 2021-07-12 14:34 ` Dr. David Alan Gilbert 2021-07-12 15:59 ` Brijesh Singh 2021-07-12 16:16 ` Dr. David Alan Gilbert 2021-07-12 16:16 ` Dr. David Alan Gilbert 2021-07-12 14:43 ` Daniel P. Berrangé 2021-07-12 14:43 ` Daniel P. Berrangé 2021-07-12 15:56 ` Brijesh Singh 2021-07-12 16:24 ` Daniel P. Berrangé 2021-07-12 16:24 ` Daniel P. Berrangé 2021-07-13 13:54 ` Brijesh Singh 2021-07-13 13:46 ` Markus Armbruster 2021-07-14 14:18 ` Brijesh Singh 2021-07-20 19:42 ` Michael Roth 2021-07-20 21:54 ` Daniel P. Berrangé 2021-07-20 21:54 ` Daniel P. Berrangé 2021-07-21 13:08 ` Markus Armbruster 2021-07-22 0:02 ` Michael Roth 2021-07-22 0:02 ` Michael Roth via 2021-07-13 18:21 ` Eric Blake 2021-07-13 18:21 ` Eric Blake 2021-07-09 21:55 ` [RFC PATCH 3/6] i386/sev: initialize SNP context Brijesh Singh 2021-07-15 9:32 ` Dov Murik 2021-07-15 9:32 ` Dov Murik 2021-07-15 13:24 ` Brijesh Singh 2021-07-09 21:55 ` [RFC PATCH 4/6] i386/sev: add the SNP launch start context Brijesh Singh 2021-07-19 12:34 ` Dov Murik 2021-07-19 12:34 ` Dov Murik 2021-07-19 15:27 ` Brijesh Singh 2021-07-09 21:55 ` [RFC PATCH 5/6] i386/sev: add support to encrypt BIOS when SEV-SNP is enabled Brijesh Singh 2021-07-14 17:08 ` Connor Kuehl 2021-07-14 17:08 ` Connor Kuehl 2021-07-14 18:52 ` Brijesh Singh 2021-07-15 5:54 ` Dov Murik 2021-07-15 5:54 ` Dov Murik 2021-07-19 13:00 ` Dov Murik [this message] 2021-07-19 13:00 ` Dov Murik 2021-07-09 21:55 ` [RFC PATCH 6/6] i386/sev: populate secrets and cpuid page and finalize the SNP launch Brijesh Singh 2021-07-14 17:29 ` Dr. David Alan Gilbert 2021-07-14 17:29 ` Dr. David Alan Gilbert 2021-07-14 18:53 ` Brijesh Singh 2021-07-19 11:24 ` Dov Murik 2021-07-19 11:24 ` Dov Murik 2021-07-19 14:45 ` Brijesh Singh 2021-07-12 17:00 ` [RFC PATCH 0/6] Add AMD Secure Nested Paging (SEV-SNP) support Tom Lendacky 2021-07-13 8:05 ` Dov Murik 2021-07-13 8:05 ` Dov Murik 2021-07-13 8:31 ` Dr. David Alan Gilbert 2021-07-13 8:31 ` Dr. David Alan Gilbert 2021-07-13 13:57 ` Brijesh Singh 2021-07-13 14:01 ` Brijesh Singh 2021-07-14 9:52 ` Dr. David Alan Gilbert 2021-07-14 9:52 ` Dr. David Alan Gilbert 2021-07-14 14:23 ` Brijesh Singh
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=0ab7b398-238e-38c5-aed1-fd39fd9c7f7c@linux.ibm.com \ --to=dovmurik@linux.ibm.com \ --cc=berrange@redhat.com \ --cc=brijesh.singh@amd.com \ --cc=ckuehl@redhat.com \ --cc=david@gibson.dropbear.id.au \ --cc=dgilbert@redhat.com \ --cc=ehabkost@redhat.com \ --cc=jejb@linux.ibm.com \ --cc=kvm@vger.kernel.org \ --cc=michael.roth@amd.com \ --cc=mst@redhat.com \ --cc=pbonzini@redhat.com \ --cc=philmd@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=thomas.lendacky@amd.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.