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@xxxxxxxxxx] Sent: Wednesday, March 6, 2019 3:36 AM To: Mohammed, Karimullah <karimullah.mohammed@xxxxxxxxx> Cc: Erik Skultety <eskultet@xxxxxxxxxx>; libvir-list@xxxxxxxxxx; Carvalho, Larkins L <larkins.l.carvalho@xxxxxxxxx>; Huang, Kai <kai.huang@xxxxxxxxx> Subject: Re: 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
