[libvirt] [PATCH 3/4] conf: introduce sev element in domain
Brijesh Singh
brijesh.singh at amd.com
Tue Feb 27 17:07:25 UTC 2018
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 at 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 ?
More information about the libvir-list
mailing list