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

[Brijesh Singh]

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.