[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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





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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]