[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v2 03/12] i386/sev: introduce 'sev-snp-guest' object
From: |
Markus Armbruster |
Subject: |
Re: [RFC PATCH v2 03/12] i386/sev: introduce 'sev-snp-guest' object |
Date: |
Wed, 01 Sep 2021 16:29:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Michael Roth <michael.roth@amd.com> writes:
> From: Brijesh Singh <brijesh.singh@amd.com>
>
> SEV-SNP support relies on a different set of properties/state than the
> existing 'sev-guest' object. This patch introduces the 'sev-snp-guest'
> object, which can be used to configure an SEV-SNP guest. For example,
> a default-configured SEV-SNP guest with no additional information
> passed in for use with attestation:
>
> -object sev-snp-guest,id=sev0
>
> or a fully-specified SEV-SNP guest where all spec-defined binary
> blobs are passed in as base64-encoded strings:
>
> -object sev-snp-guest,id=sev0, \
> policy=0x30000, \
> init-flags=0, \
> id-block=YWFhYWFhYWFhYWFhYWFhCg==, \
> id-auth=CxHK/OKLkXGn/KpAC7Wl1FSiisWDbGTEKz..., \
> auth-key-enabled=on, \
> host-data=LNkCWBRC5CcdGXirbNUV1OrsR28s..., \
> guest-visible-workarounds=AA==, \
>
> See the QAPI schema updates included in this patch for more usage
> details.
>
> In some cases these blobs may be up to 4096 characters, but this is
> generally well below the default limit for linux hosts where
> command-line sizes are defined by the sysconf-configurable ARG_MAX
> value, which defaults to 2097152 characters for Ubuntu hosts, for
> example.
>
> Co-developed-by: Michael Roth <michael.roth@amd.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> Signed-off-by: Michael Roth <michael.roth@amd.com>
> ---
> docs/amd-memory-encryption.txt | 77 ++++++++++-
> qapi/qom.json | 60 ++++++++
> target/i386/sev.c | 245 ++++++++++++++++++++++++++++++++-
> 3 files changed, 379 insertions(+), 3 deletions(-)
>
> diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
> index ffca382b5f..0d82e67fa1 100644
> --- a/docs/amd-memory-encryption.txt
> +++ b/docs/amd-memory-encryption.txt
> @@ -22,8 +22,8 @@ support for notifying a guest's operating system when
> certain types of VMEXITs
> are about to occur. This allows the guest to selectively share information
> with
> the hypervisor to satisfy the requested function.
>
> -Launching
> ----------
> +Launching (SEV and SEV-ES)
> +--------------------------
> Boot images (such as bios) must be encrypted before a guest can be booted.
> The
> MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images:
> LAUNCH_START,
> LAUNCH_UPDATE_DATA, LAUNCH_MEASURE and LAUNCH_FINISH. These four commands
> @@ -113,6 +113,79 @@ a SEV-ES guest:
> - Requires in-kernel irqchip - the burden is placed on the hypervisor to
> manage booting APs.
>
> +Launching (SEV-SNP)
> +-------------------
> +Boot images (such as bios) must be encrypted before a guest can be booted.
> The
> +MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images:
> +KVM_SNP_INIT, SNP_LAUNCH_START, SNP_LAUNCH_UPDATE, and SNP_LAUNCH_FINISH.
> These
> +four commands together generate a fresh memory encryption key for the VM,
> +encrypt the boot images for a successful launch.
> +
> +KVM_SNP_INIT is called first to initialize the SEV-SNP firmware and SNP
> +features in the KVM. The feature flags value can be provided through the
> +'init-flags' property of the 'sev-snp-guest' object.
> +
> ++------------+-------+----------+---------------------------------+
> +| key | type | default | meaning |
> ++------------+-------+----------+---------------------------------+
> +| init_flags | hex | 0 | SNP feature flags |
> ++-----------------------------------------------------------------+
> +
> +Note: currently the init_flags must be zero.
> +
> +SNP_LAUNCH_START is called first to create a cryptographic launch context
> +within the firmware. To create this context, guest owner must provide a guest
> +policy and other parameters as described in the SEV-SNP firmware
> +specification. The launch parameters should be specified as described in the
> +QAPI schema for the 'sev-snp-guest' object.
> +
> +The SNP_LAUNCH_START uses the following parameters (see the SEV-SNP
> +specification for more details):
> +
> ++--------+-------+----------+----------------------------------------------+
> +| key | type | default | meaning |
> ++--------+-------+----------+----------------------------------------------+
> +| policy | hex | 0x30000 | a 64-bit guest policy |
> +| imi_en | bool | 0 | 1 when IMI is enabled |
> +| ma_end | bool | 0 | 1 when migration agent is used |
> +| gosvw | string| 0 | 16-byte base64 encoded string for the guest |
> +| | | | OS visible workaround. |
> ++--------+-------+----------+----------------------------------------------+
> +
> +SNP_LAUNCH_UPDATE encrypts the memory region using the cryptographic context
> +created via the SNP_LAUNCH_START command. If required, this command can be
> called
> +multiple times to encrypt different memory regions. The command also
> calculates
> +the measurement of the memory contents as it encrypts.
> +
> +SNP_LAUNCH_FINISH finalizes the guest launch flow. Optionally, while
> finalizing
> +the launch the firmware can perform checks on the launch digest computing
> +through the SNP_LAUNCH_UPDATE. To perform the check the user must supply
> +the id block, authentication blob and host data that should be included in
> the
> +attestation report. See the SEV-SNP spec for further details.
> +
> +The SNP_LAUNCH_FINISH uses the following parameters, which can be configured
> +by the corresponding parameters documented in the QAPI schema for the
> +'sev-snp-guest' object.
> +
> ++------------+-------+----------+----------------------------------------------+
> +| key | type | default | meaning
> |
> ++------------+-------+----------+----------------------------------------------+
> +| id_block | string| none | base64 encoded ID block
> |
> ++------------+-------+----------+----------------------------------------------+
> +| id_auth | string| none | base64 encoded authentication information
> |
> ++------------+-------+----------+----------------------------------------------+
> +| auth_key_en| bool | 0 | auth block contains author key
> |
> ++------------+-------+----------+----------------------------------------------+
> +| host_data | string| none | host provided data
> |
> ++------------+-------+----------+----------------------------------------------+
> +
> +To launch a SEV-SNP guest (additional parameters are documented in the QAPI
> +schema for the 'sev-snp-guest' object):
> +
> +# ${QEMU} \
> + -machine ...,confidential-guest-support=sev0 \
> + -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1
> +
> Debugging
> -----------
> Since the memory contents of a SEV guest are encrypted, hypervisor access to
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 211e083727..ea39585026 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -775,6 +775,64 @@
> '*policy': 'uint32',
> '*handle': 'uint32' } }
>
> +##
> +# @SevSnpGuestProperties:
> +#
> +# Properties for sev-snp-guest objects. Many of these are direct arguments
> +# for the SEV-SNP KVM interfaces documented in the linux kernel source
> +# documentation under 'amd-memory-encryption.rst'. Additional documentation
> +# is also available in the QEMU source tree under
> +# 'amd-memory-encryption.rst'.
> +#
> +# In addition to those files, please see the SEV-SNP Firmware Specification
> +# (Rev 0.9) documentation for the SNP_INIT and
> +# SNP_LAUNCH_{START,UPDATE,FINISH} firmware interfaces, which the KVM
> +# interfaces are written against.
> +#
> +# @init-flags: as documented for the 'flags' parameter of the
> +# KVM_SNP_INIT KVM command (default: 0)
> +#
> +# @policy: as documented for the 'policy' parameter of the
> +# KVM_SNP_LAUNCH_START KVM command (default: 0x30000)
These expose the host kernel's numerical encoding of over QMP. I'm not
sure that's a good idea.
> +#
> +# @guest-visible-workarounds: 16-byte, base64-encoded blob to report
> +# hypervisor-defined workarounds, as documented
> +# for the 'gosvm' parameter of the
> +# KVM_SNP_LAUNCH_START KVM command.
> +# (default: all-zero)
> +#
> +# @id-block: 8-byte, base64-encoded blob to provide the ID Block
> +# structure documented in SEV-SNP spec, as documented for the
> +# 'id_block_uaddr' parameter of the KVM_SNP_LAUNCH_FINISH
> +# command (default: all-zero)
> +#
> +# @id-auth: 4096-byte, base64-encoded blob to provide the ID Authentication
> +# Information Structure documented in SEV-SNP spec, as documented
> +# for the 'id_auth_uaddr' parameter of the KVM_SNP_LAUNCH_FINISH
> +# command (default: all-zero)
> +#
> +# @auth-key-enabled: true if 'id-auth' blob contains the Author Key
> +# documented in the SEV-SNP spec, as documented for the
> +# 'auth_key_en' parameter of the KVM_SNP_LAUNCH_FINISH
> +# command (default: false)
> +#
> +# @host-data: 32-byte, base64-encoded user-defined blob to provide to the
> +# guest, as documented for the 'host_data' parameter of the
> +# KVM_SNP_LAUNCH_FINISH command (default: all-zero)
> +#
> +# Since: 6.2
> +##
> +{ 'struct': 'SevSnpGuestProperties',
> + 'base': 'SevCommonProperties',
> + 'data': {
> + '*init-flags': 'uint64',
> + '*policy': 'uint64',
> + '*guest-visible-workarounds': 'str',
> + '*id-block': 'str',
> + '*id-auth': 'str',
> + '*auth-key-enabled': 'bool',
> + '*host-data': 'str' } }
> +
> ##
> # @ObjectType:
> #
> @@ -816,6 +874,7 @@
> 'secret',
> 'secret_keyring',
> 'sev-guest',
> + 'sev-snp-guest',
> 's390-pv-guest',
> 'throttle-group',
> 'tls-creds-anon',
> @@ -873,6 +932,7 @@
> 'secret': 'SecretProperties',
> 'secret_keyring': 'SecretKeyringProperties',
> 'sev-guest': 'SevGuestProperties',
> + 'sev-snp-guest': 'SevSnpGuestProperties',
> 'throttle-group': 'ThrottleGroupProperties',
> 'tls-creds-anon': 'TlsCredsAnonProperties',
> 'tls-creds-psk': 'TlsCredsPskProperties',
Pretty much all Greek to me, but there are no obvious QAPI schema
no-nos, so
For the QAPI schema
Acked-by: Markus Armbruster <armbru@redhat.com>
[...]
- Re: [RFC PATCH v2 03/12] i386/sev: introduce 'sev-snp-guest' object,
Markus Armbruster <=