On 02/27/2018 05:10 AM, Daniel P. Berrangé wrote:
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@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.
Sure, this is my first stab at libvirt and will look into getting familiar with test and add them in next round.
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.
I am okay with this, how about <memory-encryption> instead of <launch-security>, are you okay with it ?