On Wed, Feb 28, 2018 at 10:34:51AM +0100, Erik Skultety wrote:
On Tue, Feb 27, 2018 at 05:15:30PM +0000, Daniel P. Berrangé wrote:
On Tue, Feb 27, 2018 at 11:07:25AM -0600, Brijesh Singh wrote:
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 ?
Memory encryption is a very specific feature. It occurs to me that there could in future be other features that use launch time validation, that are not memory encryption related.
<launch-security> is IMHO still rather specific than generic, since we might need to enable features in the future, which might/might no rely on security, but add additional attributes to the launch validation, in which case I think going for something like <launch-control> or simply <launch> and having a structure similar to the one below:
Any kind of launch validation is ultimately security related in some manner.
By having the separate <sev> element you can make the sub-elements depend on this parent element, since you can't expect other vendors to favour <cbitpos> which add burden to the documentation to make it clear. Of course, the price you pay for this is a more complex XML structure. <launch> <security> <sev> <sev_specific_elements/> </sev> </security>
This is not the way we usually do things - we wuld have a type="sev|..." which determines what child elements are permitted, as illustrated in the example above.
<other_security_unrelated_validation_options/> </launch>
I think the extra level of nesting is uneccessary 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 :|