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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list