On Mon, Feb 26, 2018 at 11:53:35AM -0600, Brijesh Singh wrote:
Secure Encrypted Virtualization (sev) element is used to provide the
guest
owners input parameters used for creating an encrypted VM using AMD SEV
feature. SEV feature supports running encrypted VM under the control of
KVM. Encrypted VMs have their pages (code and data) secured such that only
the guest itself has access to the unencrypted version. Each encrypted VM
is associated with a unique encryption key; if its data is accessed to a
different entity using a different key the encrypted guests data will be
incorrectly decrypted, leading to unintelligible data.
QEMU >= 2.12 provides 'sev-guest' object which supports launching encrypted
VMs. A typical command line
# $QEMU ... \
-machine memory-encryption=sev0 \
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 \
...
Signed-off-by: Brijesh Singh <brijesh.singh(a)amd.com>
---
docs/formatdomain.html.in | 71 +++++++++++++++++++++++++++++++++++++++++++
src/conf/domain_conf.c | 64 +++++++++++++++++++++++++++++++++++++++
src/conf/domain_conf.h | 18 +++++++++++
src/qemu/qemu_command.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 230 insertions(+)
In general we'd expect to see additions to the test suite for any XML
changes. eg a qemuxml2xmltest and qemuxml2argvtest addition.
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 6fd2189cd2f4..d18e3fb1d976 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -8195,6 +8195,77 @@ qemu-kvm -net nic,model=? /dev/null
<p>Note: DEA/TDEA is synonymous with DES/TDES.</p>
+ <h3><a id="sev">Secure Encrypted Virtualization
(SEV)</a></h3>
+
+ <p>
+ The contents of the <code>sev</code> element is used to provide the
+ guest owners input used for creating an encrypted VM using the AMD
+ Secure Encrypted Virtualization (SEV) feature.
+
+ SEV is an extension to the AMD-V architecture which supports running
+ encrypted virtual machine (VMs) under the control of KVM. Encrypted
+ VMs have their pages (code and data) secured such that only the guest
+ itself has access to the unencrypted version. Each encrypted VM is
+ associated with a unique encryption key; if its data is accessed to a
+ different entity using a different key the encrypted guests data will
+ be incorrectly decrypted, leading to unintelligible data.
+ </p>
+ <pre>
+<domain>
+ ...
+ <sev>
+ <policy> 1 </policy>
+ <cbitpos> 47 </cbitpos>
+ <reduced-phys-bits> 5 </reduced-phys-bits>
+ <session> ... </session>
+ <dh-cert> ... </dh>
+ </sev>
Minor nitpick - since this inheranted SEV specific, I think we could do
with having a generic top level element with a type=sev. eg
<launch-security type="sev">
<policy>...</policy>
<cbitpos>..</cbitpos>
...etc...
</launch>
then we can plug in custom data if other vendors invent competing
solutions to AMD's SEV.
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 :|