All of lore.kernel.org
 help / color / mirror / Atom feed
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"
> 


  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: link
Be 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.