[libvirt] New Feature: Intel MKTME Support

[Erik Skultety]

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