Re: [RFC PATCH v2 03/12] i386/sev: introduce 'sev-snp-guest' object

[Michael Roth]

On Wed, Sep 01, 2021 at 04:29:03PM +0200, Markus Armbruster wrote:
> 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.

Most of these are the same as the actual arguments to firmware as defined by
the SNP spec, but I'll see if I can make the documentation here more
agnostic to the kernel interfaces and try to stick more to the SNP/firmware
spec.

> 
> > +#
> > +# @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>
> 
> [...]

Thanks!