Hi Erik and Daniel,
Earlier we were considering a different method of accessing Linux kernel ring services to get a key-handle i.e through daemon process in openstack. But later on we decided to do it through the Libvirt as Daemon processes is not feasible in Openstack. Hence we had separate calls for getting key-handle and using that key launching VM through Libvirt.
However we are open for, the idea of getting key-handle during startup of Libvirt. Looks like getting key-handle in QEMU is not possible because of some limitations in the code it seems(we will give you more info on this one, once we have accurate information from our QEMU team).
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
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.
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).
AMS SEV and MKTME are not quite similar, but we are open to execute key-handle get/set operations in libvirt at this point. We have seen lot of pros in executing the things the way you were proposing. Like, the key leakage, number of calls to Libvirt will be minimized and less Nova code and modification.
We really appreciate your suggestions and advices , hope the above explanation helps understand our design. We are open for any changes , that gives us a good design in libvirt.
Here is the link to mktme spec : https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf
Thanks again
Karim.
-----Original Message-----
From: Erik Skultety [mailto:eskultet@xxxxxxxxxx]
Sent: Wednesday, March 6, 2019 12:08 AM
To: Daniel P. Berrangé <berrange@xxxxxxxxxx>
Cc: Mohammed, Karimullah <karimullah.mohammed@xxxxxxxxx>; libvir-list@xxxxxxxxxx; Carvalho, Larkins L <larkins.l.carvalho@xxxxxxxxx>
Subject: Re: New Feature: Intel MKTME Support
On Tue, Mar 05, 2019 at 05:35:09PM +0000, Daniel P. Berrangé wrote:
> On Tue, Mar 05, 2019 at 05:23:04PM +0000, Mohammed, Karimullah wrote:
> > Hi Daniel,
> > MKTME supports encryption of memory(NVRAM) for Virtual
> > Machines(hardware based encryption). This features uses Linux kernel key ring services, i.e.
> > Operations like, allocation and clearing of secret/keys. These keys
> > are used in encryption of memory in Virtual machines. So MKTME
> > provided encryption of entire RAM of a VM, allocated to it, thereby
> > supporting VM isolation feature.
> >
> > So to implement this functionality in openstack
> >
> > 1. Nova executes host capability command, to identify if the hardware
> > support for MKTME (openstack xml host_capabilities command request
> > -->> libvirt ->> QEMU)-- qemu monitoring commands 2. Once the
> > hardware is identified and if user configures mktme policy
> > to launch a VM in openstack, Nova
> > a. Sends a new xml command request to libvirt, then libvirt makes
> > a syscall to Linux kernel key ring services to get/retrieve a
> > key/key-handle for this VM ( we are not sure at this point
> > whether to make this syscall directly in libvirt or through
> > QEMU)
>
> What will openstack do with the key / key-handle it gets back from
> libvirt ?
Same question here.
>
> Why does it need to allocate one before starting the VMs, as opposed
> to letting QEMU or libvirt allocate it during startup ?
>
> By allocating it separately from the VM start request it opens the
> possibility for leaking keys, if VM startup fails and the mgmt app
> doesn't release the now unused key.
I would expect this key/handle work similarly as it does with SEV, we (libvirt) treat everything as a blob since the session key is encrypted by a transport key shipped along with an integrity key which were derived by a master secret both parties know.
My question is whether you have a draft of this MKTME spec that we could have a look at to give us more technical insight and therefore help us to make better design decisions.
>
> > b. Once the key is retrieved , Nova compute executes a VM launch
> > xml command request to libvirt with a new argument called
> > mktme- keyhandle , which will send a command request to QEMU
> > to launch the VM( We are in process of supporting this
> > functionality in QEMU for VM launch operation, with new
> > mktme-key argument)
As Dan asked above, this really depends on why does openstack need to interact with the key and whether the key handle can be computed during the launch phase. For example, in SEV's case we pass the VM owner's certificate to the SEV firmware as part of the VM configuration and the handshake and a measurement verification both happen after we initialized QEMU and if necessary (measurement purposes) we start the VM in the paused state so that commands can be passed to QEMU handling all the interactions with SEV in the kernel instead of us.
Thanks,
Erik
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
