[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] TPM support in libvirt



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]