[libvirt] New Feature: Intel MKTME Support

[Daniel P. Berrangé]

BTW, if possible, could you configure your email client to line
wrap text at 72 columns. It is currently sending messages with
no line breaks except at end of paragraph which means I have to
word wrap your quoted text myself when replying. 

On Wed, Mar 06, 2019 at 10:27:59AM +0000, Mohammed, Karimullah wrote:
> We want to understand following things in virtualization.
> 
> 1. What do you mean by " letting QEMU or libvirt to allocate key-handle 
>  during startup ?. Is this means, before launching a VM get key-handle 
> in either in Libvirt/QEMU?.. if so next tpoint

I mean do it during the virDomainCreate  API call, which is the call
a mgmt app already makes to start a VM.

> 2. If not in QEMU, can we make Linux syscalls to get key-handle before
>  launching  a command to QEMU during VM launch? In Libvirt?  like
> 
> 	. Nova compute  during launch of an VM , sends mktme policy
>         in the same xml file to Libvirt.
>       . Libvirt makes kernel syscall to get key-handle and then 
>         sends QEMU command to launch the VM with addition of 
>         key-handle parameter
> 
> Here is the brief presentation of, how we plan to execute mtkme 
> end to end in openstack, so that we are on same page..
> 1. Cloud service provider(CSP) launches a VM instance using  mktme
>    policy in Image meta-data
> 	Mktme-policy {
> 			Mktme-key-id = "Mname1" (String),
> 			Mktme-key-type = cpu or user (CPU = hardware
>                                        generated key, user = user given key)
> 			Mktme-key-url  = https://xx.xx.xx ( URL to fetch the key)
> 			}
> 2. After all checks , Nova compute will get a command to launch a VM, 
>    if mtkme-policy to be found. If mktme-key-type is user, it gets the
>    key from the url specified in mktme-key-url and that key is called 
>    mktme-key. If mktme-key-type is cpu no action and mktme-key will be
>    null.
> 
> 3. Assuming key-handle and VM launch are separate calls. Nova compute 
>    execute a new libvirt command to get the key-handle given the
>    arguments { Mktme-key-id, Mktme-key-type, Mktme-key(if user type key). }. 
> 	a. Libvirt make a Linux kernel ring service syscall request_key(
>          with above parameters), request_key syscall return a key-handle 
>          if a key exist with mktme-key-id or it will create a new 
>          key-handle and returns it. This is true for both user and cpu
>          type keys. (Now this command can also be extended/execute in QEMU)
>       b. Nova gets the key-handle in return and launched the VM instance 
>          using this additional key-handle argument to Libvirt again.

Nova is requesting a value from libvirt and then feeding it straight
back to libvirt. This is the bit that looks pointless to me. It is
appearing to add an extra API call for no benefit.

The only reason to have a seperate API call is if Nova needs to do
some kind of computational work with the key it gets in step (a)
before it then gives it back to libvirt in step (b).

> 4. Assuming key-handle is done in Libvirt( if I'm not mistaken, this what
>    you were proposing). Nova compute execute VM launch libvirt call using 
>    mktme additional parameters { Mktme-key-id, Mktme-key-type, Mktme-key
>    (if user type key, ). }
>      a. Libvirt upon receiving this call , execute request_key kernel 
>         syscall using the above parameters and gets the key-handle and 
>         thereby launches  the VM using the usual QEMU command with 
>         addition parameter of mktme key-handle. And again this whole
>         process can also get executed in QEMU, but we have some limitation
>         I guess at this point).

I think libvirt would still talk to the kernel to get the key. Since the
keys are a finite resource, we don't want to give QEMU the permission to
request keys itself as that opens a denial of service possibility. QEMU
should only be able to use keys it has been given by libvirt, which means
libivrt must request them from the kernel.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|