[libvirt] TPM support in libvirt

[Stefan Berger]

Hello!

   I'd like to start a discussion and get some feedback on support for 
TPM (Trusted Platform Module) management in libvirt. I have been posting 
patches to the Qemu and SeaBIOS mailing lists that will provide the 
ground work for TPM support in Qemu, though I anticipate that it will 
take a while until the code goes into those repositories. So everything 
I am saying related to command lines etc. can still change. 
Nevertheless, the next obvious layer for support is libvirt. Well, and I 
do have patches...

   First some background: the TPM is a crypto device built into many 
modern laptops and desktops. It's a chip connected to the motherboard 
and has firmware for running the TPM specifications. I would say it has 
a full processor on its own to run this firmware. It also has some very 
limited space for persistent storage to permanently store for example 
the owner's password (that he can establish with the TPM), store private 
keys and it also has some area for NVRAM spaces where the user can put 
any data into it he wants to.

   So now, on the qemu command line the TPM support (currently) looks as 
follows:

... -tpm ?

displays:

Supported TPM types (choose only one):
builtin   Qemu's built-in TPM; requires 63kb of block storage

I use this for reading the size of the necessary (QCoW2) blockstorage 
from it, 63kb.

To start a VM with TPM support:

... -tpm type=builtin,path=/tmp/tpmstate.bin

   The above indicates the type of TPM to use. Currently there is only 
one type available, which is the 'builtin' one. It also provides a path 
to persistent storage, here /tmp/tpmstate.bin. The persistent storage 
file is actually a Qcow2 file so we can properly support snapshotting of 
the image and the TPM and go back to different states.

   Obviously we are now adding another 'disk' to the VM, so that the TPM 
can store its own persistent data. Now a user has to make sure to always 
keep his image file and this TPM 'disk' together, particularly once he 
stores vital keys in the TPM.

   So now for modeling this in libvirt I thought of this XML here for a 
user-provided Qcow2 image:

<tpm type='built-in'>
<storage file='/tmp/tpmstate.bin'/>
</tpm>

  In this case the user would create the above QCoW2 /tmp/tmpstate.bin 
at the appropriate size (63kb).

   This XML here is for a libvirt-created QCoW2 image:

<tpm type='built-in'>
<storage/>
</tpm>

   This then causes libvirt to create a QCoW2 image of 63kb size (reads 
the 63kb from .. tpm ?) once the VM is about to start and produces for 
example this command line:

-tpm 
type=builtin,path=/var/lib/libvirt/tpm/a4d7cd22-da89-3094-6212-079a48a309a1.bin

The UUID then corresponds to the UUID of the VM. Since only one TPM per 
VM is supported, this should work just fine.


  Now to support an encrypted QCoW2 image, the following XML could be used:

<tpm type='built-in'>
<storage>
<encryption format='qcow'>
<secret type='passphrase' uuid='13ea49f7-2553-7308-5168-e337ade36232'/>
</encryption>
</storage>
</tpm>

  Here the user has created a 'secret' and passes that secret's UUID 
into the XML above. So this is similar to how storage is dealt with with 
the difference that no path to the storage is provided and also 
internally no comparisons for storage paths are being made. I did also 
not want to force the user to create storage spaces (volumes) on his 
own, but let libvirt handle this implicitly for the TPM (use qemu-img to 
create the QCoW2). Also, multiple VMs' TPMs could share the same secret.

  Please let me know of any comments regarding this.

  I'll post the patches as RFC later on.

Regards,
   Stefan