[libvirt] TPM support in libvirt

[Stefan Berger]

On 03/31/2011 10:15 AM, Daniel P. Berrange wrote:
> On Thu, Mar 31, 2011 at 09:41:44AM -0400, Stefan Berger wrote:
>> <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.
> I'm not sure I'm a fan of the idea of libvirt creating the TPM
> qcow2 file itself at VM startup, since that's at odds with the
> way we deal with other host OS resources where the app is required
> to create everything the VM needs upfront.
One fact is that the TPM Qemu works with will have a certain space 
requirement, i.e., the QCoW2 will have to be of a certain size so that 
all state that needs to be persisted fits on it. So, I thought I'd make 
it easier on the user to not have to think of the persistent storage of 
the TPM and its size requirements when he wants to have a TPM connected 
to the VM, but let libvirt handle it transparently. Mostly I think it's 
the convenience factor, but I do find it compelling. The code does 
support both models with and without user-provided storage.
> Also, why QCow2 ? It seems like rather a large hammer, if all we
> really need is to ensure the data is encrypted on disk.
QCoW2 is currently the only file format that allows the most wide range 
of operations, i.e., supports snapshotting of the TPM parallel to the 
VM. Any other format would prevent snapshotting VMs with attached TPM. I 
don't think that would be a good choice.

> Might it be better to just use a raw 64kb file and just give QEMU
> a decryption key to use for it. It should be trivial for QEMU to
> have a variant on the raw block driver which passes all data
> writes/reads through an encrypt/decrypt API. QCow2 is not exactly
> everyone's favourite bit of QEMU code, being rather complex and
> unreliable at times.
To me this was about supporting the widest variety of VM operations 
possible. QCoW2 does that, then there is also the FVD proposed format, 
which we could also use in the future. Maybe that would address the 
QCoW2 concerns, but that decision on that format is up to the QEmu 
community, of course.
>>   Please let me know of any comments regarding this.
> My other main thought is how does the Xen TPM model fit in ? That has been
> around for quite a while, but not supported in libvirt. If we add TPM to
> libvirt we need to make sure the way we model it works for Xen too.
> Not sure if anyone else like VMWare/VirtualBox does any TPM stuff yet.
I think for the current Xen TPM model the XML not supporting encryption 
would be sufficient. It maybe possible to support it with or without 
provided filename - not sure about that, but libvirt could refuse to 
start the VM if in the Xen case the filename was not explicitly provided 
by the user. As for an encryption key, I believe it could be pulled from 
the 'secret' storage.

I cannot speak (at all) for the other technologies whether and how they 
may support it in the future.

Regards,
    Stefan