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