[libvirt] [PATCH 3/4] conf: introduce sev element in domain

Brijesh Singh brijesh.singh at amd.com
Tue Feb 27 17:40:45 UTC 2018



On 02/27/2018 11:15 AM, 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 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 ?
> 
> 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.
> 


Understood, I am good with launch-security tag. thanks




More information about the libvir-list mailing list