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

[Brijesh Singh]

On 05/29/2018 10:28 AM, Brijesh Singh wrote:

...

> 
> 
> 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.
> 
> 
> 


I have not seen any other feedbacks, hence I will go with Erik's 
suggestions. I am reworking the patch to expose a new API 
"virNodeGetSEVParameters()". The API can be used to retrieve the SEV 
certificates etc. The signature looks like this:



# define VIR_NODE_SEV_PDH               "pdh"
# define VIR_NODE_SEV_CERT_CHAIN        "cert-chain"
# define VIR_NODE_SEV_CBITPOS		"cbipos"
# define VIR_NODE_SEV_REDUCED_PHYS_BITS	"reduced-phys-bits"

int  virNodeGetSEVParameters (virConnectPtr conn,
                               virTypedParameterPtr params,
                               int *nparams,
                               unsigned int flags)

If anyone have better idea then please let me know. thanks