Re: [libvirt] New Feature: Intel MKTME Support
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 :|