1. Patchew
  2. Libvirt
  3. [libvirt] [PATCH v2 0/9] x86: Secure Encrypted Virtualization (AMD)
  4. View patch

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

Brijesh Singh posted 9 patches 7 years, 2 months ago
There is a newer version of this series
[libvirt] [PATCH v2 2/9] qemu: introduce SEV feature in hypervisor capabilities
Posted by Brijesh Singh 7 years, 2 months ago 
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@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 @@
         &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_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);
+    virBufferAdjustIndent(buf, -2);
+    virBufferAddLit(buf, "</sev>\n");
+}
+
 
 char *
 virDomainCapsFormat(virDomainCapsPtr const caps)
@@ -587,6 +606,7 @@ virDomainCapsFormat(virDomainCapsPtr const caps)
     virBufferAdjustIndent(&buf, 2);
 
     virDomainCapsFeatureGICFormat(&buf, &caps->gic);
+    virDomainCapsFeatureSEVFormat(&buf, caps->sev);
 
     virBufferAdjustIndent(&buf, -2);
     virBufferAddLit(&buf, "</features>\n");
diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h
index 83d04d4c8506..2239566105fd 100644
--- a/src/conf/domain_capabilities.h
+++ b/src/conf/domain_capabilities.h
@@ -170,6 +170,7 @@ struct _virDomainCaps {
     /* add new domain devices here */
 
     virDomainCapsFeatureGIC gic;
+    virSEVCapabilityPtr sev;
     /* add new domain features here */
 };
 
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 68e3622a3963..f56e88032c06 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -5975,6 +5975,8 @@ virQEMUCapsFillDomainCaps(virCapsPtr caps,
         virQEMUCapsFillDomainDeviceHostdevCaps(qemuCaps, hostdev) < 0 ||
         virQEMUCapsFillDomainFeatureGICCaps(qemuCaps, domCaps) < 0)
         return -1;
+
+    domCaps->sev = qemuCaps->sevCapabilities;
     return 0;
 }
 
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 2/9] qemu: introduce SEV feature in hypervisor capabilities
Posted by Daniel P. Berrangé 7 years, 2 months ago 
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@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 @@
>          &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_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 ?

> +    virBufferAdjustIndent(buf, -2);
> +    virBufferAddLit(buf, "</sev>\n");
> +}
> +
>  
>  char *
>  virDomainCapsFormat(virDomainCapsPtr const caps)
> @@ -587,6 +606,7 @@ virDomainCapsFormat(virDomainCapsPtr const caps)
>      virBufferAdjustIndent(&buf, 2);
>  
>      virDomainCapsFeatureGICFormat(&buf, &caps->gic);
> +    virDomainCapsFeatureSEVFormat(&buf, caps->sev);
>  
>      virBufferAdjustIndent(&buf, -2);
>      virBufferAddLit(&buf, "</features>\n");
> diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h
> index 83d04d4c8506..2239566105fd 100644
> --- a/src/conf/domain_capabilities.h
> +++ b/src/conf/domain_capabilities.h
> @@ -170,6 +170,7 @@ struct _virDomainCaps {
>      /* add new domain devices here */
>  
>      virDomainCapsFeatureGIC gic;
> +    virSEVCapabilityPtr sev;
>      /* add new domain features here */
>  };
>  
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 68e3622a3963..f56e88032c06 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -5975,6 +5975,8 @@ virQEMUCapsFillDomainCaps(virCapsPtr caps,
>          virQEMUCapsFillDomainDeviceHostdevCaps(qemuCaps, hostdev) < 0 ||
>          virQEMUCapsFillDomainFeatureGICCaps(qemuCaps, domCaps) < 0)
>          return -1;
> +
> +    domCaps->sev = qemuCaps->sevCapabilities;
>      return 0;
>  }

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 2/9] qemu: introduce SEV feature in hypervisor capabilities
Posted by Brijesh Singh 7 years, 2 months ago 

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@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 @@
>>           &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_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.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 2/9] qemu: introduce SEV feature in hypervisor capabilities
Posted by Daniel P. Berrangé 7 years, 2 months ago 
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@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 @@
> > >           &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_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 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Patchew 2.1-devel-8c64711

© 2016 - 2025 Red Hat, Inc.