3:30 p.m.
Hi Daniel,
Thank you for your valuable suggestion and we started looking into Libvirt code in that
perspective
and will soon send a low level design for our implementation of keyctl calls in Libvirt.
We will put together QEMU monitoring commands as well as vm launch, using mktme
keys in one design doc and will share with you all.
Thanks
Karim
P. S : Was not able to set the wrapper in outlook for some reason, still figuring out the
issue.
Meanwhile adding line breaks , hope this is good.
-----Original Message-----
From: Daniel P. Berrangé [mailto:berrange@redhat.com]
Sent: Wednesday, March 6, 2019 3:36 AM
To: Mohammed, Karimullah <karimullah.mohammed(a)intel.com>
Cc: Erik Skultety <eskultet(a)redhat.com>; libvir-list(a)redhat.com; Carvalho, Larkins L
<larkins.l.carvalho(a)intel.com>; Huang, Kai <kai.huang(a)intel.com>
Subject: 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 :|