[libvirt] [PATCH v2 2/9] qemu: introduce SEV feature in hypervisor capabilities
Daniel P. Berrangé
berrange at redhat.com
Mon Mar 12 15:37:50 UTC 2018
On Mon, Mar 12, 2018 at 10:25:44AM -0500, Brijesh Singh wrote:
>
>
> On 03/12/2018 08:33 AM, Daniel P. Berrangé wrote:
> > On Thu, Mar 08, 2018 at 11:12:01AM -0600, Brijesh Singh wrote:
> > > Extend hypervisor capabilities to include sev feature. When available,
> > > hypervisor supports launching an encrypted VM on AMD platform. The
> > > sev feature tag provides additional details like platform diffie-hellman
> > > key and certificate chain which can be used by the guest owner to
> > > establish a cryptographic session with the SEV firmware to negotiate
> > > keys used for attestation or to provide secret during launch.
> > >
> > > Signed-off-by: Brijesh Singh <brijesh.singh at amd.com>
> > > ---
> > > docs/formatdomaincaps.html.in | 40 ++++++++++++++++++++++++++++++++++++++++
> > > docs/schemas/domaincaps.rng | 20 ++++++++++++++++++++
> > > src/conf/domain_capabilities.c | 20 ++++++++++++++++++++
> > > src/conf/domain_capabilities.h | 1 +
> > > src/qemu/qemu_capabilities.c | 2 ++
> > > 5 files changed, 83 insertions(+)
> > >
> > > diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in
> > > index 6bfcaf61caae..f38314166ac3 100644
> > > --- a/docs/formatdomaincaps.html.in
> > > +++ b/docs/formatdomaincaps.html.in
> > > @@ -417,6 +417,12 @@
> > > <value>3</value>
> > > </enum>
> > > </gic>
> > > + <sev>
> > > + <pdh> </pdh>
> > > + <cert-chain> </cert-chain>
> > > + <cbitpos> </cbitpos>
> > > + <reduced-phys-bits> </reduced-phys-bits>
> > > + </sev>
> > > </features>
> > > </domainCapabilities>
> > > </pre>
> > > @@ -441,5 +447,39 @@
> > > <code>gic</code> element.</dd>
> > > </dl>
> > > + <h4><a id="elementsSEV">SEV capabilities</a></h4>
> > > +
> > > + <p>AMD Secure Encrypted Virtualization (SEV) capabilities are exposed under
> > > + the <code>sev</code> element.
> > > + SEV is an extension to the AMD-V architecture which supports running
> > > + virtual machines (VMs) under the control of a hypervisor. When supported,
> > > + guest owner can create a VM whose memory contents will be transparently
> > > + encrypted with a key unique to that VM.
> > > +
> > > + For more details on SEV feature see:
> > > + <a href="https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf">
> > > + SEV API spec</a> and <a href="http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf">
> > > + SEV White Paper</a>
> > > +
> > > + </p>
> > > +
> > > + <dl>
> > > + <dt><code>pdh</code></dt>
> > > + <dd>Platform diffie-hellman key, which can be exported to remote entities
> > > + which wish to establish a secure transport context with the SEV platform
> > > + in order to transmit data securely. The key is encoded in base64</dd>
> > > + <dt><code>cert-chain</code></dt>
> > > + <dd> Platform certificate chain -- which includes platform endorsement key
> > > + (PEK), owners certificate authory (OCA) and chip endorsement key (CEK).
> > > + The certificate chain is encoded in base64.</dd>
> > > + <dt><code>cbitpos</code></dt>
> > > + <dd>When memory encryption is enabled, one of the physical address bit
> > > + (aka the C-bit) is utilized to mark if a memory page is protected. The
> > > + C-bit position is Hypervisor dependent.</dd>
> > > + <dt><code>reduced-phys-bits</code></dt>
> > > + <dd>When memory encryption is enabled, we loose certain bits in physical
> > > + address space. The number of bits we loose is hypervisor dependent.</dd>
> > > + </dl>
> > > +
> > > </body>
> > > </html>
> > > diff --git a/docs/schemas/domaincaps.rng b/docs/schemas/domaincaps.rng
> > > index 39053181eb9a..53b33eb83c1f 100644
> > > --- a/docs/schemas/domaincaps.rng
> > > +++ b/docs/schemas/domaincaps.rng
> > > @@ -173,6 +173,9 @@
> > > <element name='features'>
> > > <interleave>
> > > <ref name='gic'/>
> > > + <optional>
> > > + <ref name='sev'/>
> > > + </optional>
> > > </interleave>
> > > </element>
> > > </define>
> > > @@ -184,6 +187,23 @@
> > > </element>
> > > </define>
> > > + <define name='sev'>
> > > + <element name='sev'>
> > > + <element name='pdh'>
> > > + <data type='string'/>
> > > + </element>
> > > + <element name='cert-chain'>
> > > + <data type='string'/>
> > > + </element>
> > > + <element name='cbitpos'>
> > > + <data type='unsignedInt'/>
> > > + </element>
> > > + <element name='reduced-phys-bits'>
> > > + <data type='unsignedInt'/>
> > > + </element>
> > > + </element>
> > > + </define>
> > > +
> > > <define name='value'>
> > > <zeroOrMore>
> > > <element name='value'>
> > > diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c
> > > index f7d9be50f82d..082065fb4733 100644
> > > --- a/src/conf/domain_capabilities.c
> > > +++ b/src/conf/domain_capabilities.c
> > > @@ -549,6 +549,25 @@ virDomainCapsFeatureGICFormat(virBufferPtr buf,
> > > FORMAT_EPILOGUE(gic);
> > > }
> > > +static void
> > > +virDomainCapsFeatureSEVFormat(virBufferPtr buf,
> > > + virSEVCapabilityPtr const sev)
> > > +{
> > > + if (!sev)
> > > + return;
> > > +
> > > + virBufferAddLit(buf, "<sev supported='yes'>\n");
> > > + virBufferAdjustIndent(buf, 2);
> > > + virBufferAsprintf(buf, "<cbitpos>%d</cbitpos>\n", sev->cbitpos);
> > > + virBufferAsprintf(buf, "<reduced-phys-bits>%d</reduced-phys-bits>\n",
> > > + sev->reduced_phys_bits);
> > > + virBufferAsprintf(buf, "<pdh>%s</pdh>\n", sev->pdh);
> > > + virBufferAsprintf(buf, "<cert-chain>%s</cert-chain>\n",
> > > + sev->cert_chain);
> >
> > I wonder what length 'cert_chain' is going to be typically ? I hope we
> > don't cause ourselves any trouble by having the data inline in the main
> > capabilities XML ?
>
>
> The PDH is 2K and cert-chain length is 8K. A quick google indicates that a
> maximum data length in XML can be up to 64000 bytes.
64kb is a fairly arbitrary cap we place on it in the RPC protocol, but we
have freedom to extend it.
I wonder if putting 8k of certs into the domain capabilities XML is good
idea though, even if possible.
Does anyone else have an opinion about that, or should we perhaps have a
separate API to fetch the PDH / Cert data, and use the domain capabilities
merely to indicate existance of the SEV feature (and the bit field stuff)
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the libvir-list
mailing list