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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxx>
---
  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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux