Re: [libvirt] [PATCH v2 2/9] qemu: introduce SEV feature in hypervisor capabilities

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(a)amd.com&gt; > > --- > > 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 @@ > > &lt;value&gt;3&lt;/value&gt; > > &lt;/enum&gt; > > &lt;/gic&gt; > > + &lt;sev&gt; > > + &lt;pdh&gt; &lt;/pdh&gt; > > + &lt;cert-chain&gt; &lt;/cert-chain&gt; > > + &lt;cbitpos&gt; &lt;/cbitpos&gt; > > + &lt;reduced-phys-bits&gt; &lt;/reduced-phys-bits&gt; > > + &lt;/sev&gt; > > &lt;/features&gt; > > &lt;/domainCapabilities&gt; > > </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_Specificat... > > + SEV API spec</a> and <a href="http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12... > > + 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.