[libvirt] [PATCH v6 0/9] x86: Secure Encrypted Virtualization (AMD)

Brijesh Singh brijesh.singh at amd.com
Tue May 29 15:28:24 UTC 2018



On 05/28/2018 05:06 AM, Erik Skultety wrote:
> On Wed, May 23, 2018 at 04:18:25PM -0500, Brijesh Singh wrote:
>> This patch series provides support for launching an encrypted guest using
>> AMD's new Secure Encrypted  Virtualization (SEV) feature.
>>
>> SEV is an extension to the AMD-V architecture which supports running
>> multiple VMs under the control of a hypervisor. When enabled, SEV feature
>> allows the memory contents of a virtual machine (VM) to be transparently
>> encrypted with a key unique to the guest VM.
>>
>> At very high level the flow looks this:
>>
>> 1. mgmt tool calls virConnectGetDomainCapabilities. This returns an XML document
>> that includes the following
>>
>> <feature>
>> ...
>>    <sev supported='yes'>
>>      <cbitpos> </cbitpos>
>>      <reduced-phys-bits> </reduced-phys-bits>
>>      <pdh> </pdh>
>>      <cert-chain> </cert-chain>
>> </feature>o
> 
> It's sad that ^this didn't get more attention since Dan suggested a separate
> API to get the certificates, because I myself don't feel like having 2k/8k
> base64 strings reported in domain capabilities is a good idea, it should only
> report that the capability is supported with the given qemu and that the bit
> stuff which is hypervisor specific. For the certificates,  which are not QEMU
> specific, rather those are platform dependent and static, we should introduce a
> virNodeGetSEVInfo (or something like that - I'm not good with names, but I
> think we struggle with this in general) getter for that which would work on top
> of virTypedParams so that it's extensible. Moreover, it would also be okay IMHO
> to feed the return data of this new API not only with the certs but also with
> the bit-related stuff, even though that's already obtained through
> capabilities.
> 
> 
>>


IIRC, Dan asked other folks to comment their preferences on APIs vs xml. 
I don't remember seeing any strong preferences hence I didn't rework on 
that code. But if majority of folks think that we should do APIs then I 
can certainly rework it in next patch.



>> If <sev> is provided then we indicate that hypervisor is capable of launching
>> SEV guest.
>>
>> 2. (optional) mgmt tool can provide the PDH and Cert-chain to guest owner in case
>> if guest owner wish to establish a secure connection with SEV firmware to
>> negotiate a key used for validating the measurement.
>>
>> 3. mgmt tool requests to start a guest calling virCreateXML(), passing VIR_DOMAIN_START_PAUSED.
>> The xml would include
>>
>> <launch-security type='sev'>
>>    <cbitpos> </cbitpos>  /* the value is same as what is obtained via virConnectGetDomainCapabilities()
>>    <reduced-phys-bits> </reduced-phys-bits>  /* the value is same as what is obtained via virConnectGetDomainCapabilities()
>>    <dh-cert> .. </dh> /* guest owners diffie-hellman key */ (optional)
>>    <session> ..</session> /* guest owners session blob */ (optional)
>>    <policy> ..</policy> /* guest policy */ (optional)
>> </launch-security>
> 
> Now that I'm looking at the design, why do we need to report <cbitpos>,
> <reduced-phys-bits> in the domain XML if that is platform specific, it's static
> and we already report it withing capabilities? If it can't be used for a
> per-guest configuration, i.e. it can change, I don't think we should expose the
> same information on multiple places.
> 



We had some discussion about this on QEMU mailing list. To make SEV 
launch migration safe, we require user to provide the cbitpos and 
reduced-phys-bit in domain XML as an input to the launch flow. The 
launch flow should not make a platform dependent call to obtain these 
value. If user does not know the cbitpos for its given platform then it 
can obtain it through the domain capabilities.



> Still, does anyone have another idea for an improvement?
> 
> Erik
> 




More information about the libvir-list mailing list