Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external
From:
Stefan Berger
Subject:
Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM
Date:
Wed, 20 Jan 2016 15:16:14 -0500
Stefan Berger/Watson/IBM wrote on 01/20/2016 02:51:58
PM:
> "Daniel P. Berrange" <address@hidden> wrote on
01/20/2016 10:42:09 AM: > > > > > On Wed, Jan 20, 2016 at 10:23:50AM -0500, Stefan Berger wrote: > > > "Daniel P. Berrange" <address@hidden>
wrote on 01/20/2016 09:58:39 > > > AM: > > > > > > > > > > Subject: Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM
support with a > > > > QEMU-external TPM > > > > > > > > On Mon, Jan 04, 2016 at 10:23:18AM -0500, Stefan Berger
wrote: > > > > > The following series of patches extends TPM support
with an > > > > > external TPM that offers a Linux CUSE (character
device in userspace) > > > > > interface. This TPM lets each VM access its own
private vTPM. > > > > > > > > What is the backing store for this vTPM ? Are the vTPMs
all > > > > multiplexed onto the host's physical TPM or is there
something > > > > else going on ? > > > > > > The vTPM writes its state into a plain file. In case the
user started the > > > vTPM, the user gets to choose the directory. In case of
libvirt, libvirt > > > sets up the directory and starts the vTPM with the directory
as a > > > parameter. The expectation for VMs (also containers) is
that each VM can > > > use the full set of TPM commands with the vTPM and due to
how the TPM > > > works, it cannot use the hardware TPM for that. SeaBIOS
has beenextended > > > with TPM 1.2 support and initializes the vTPM in the same
way it would > > > initialize a hardware TPM. > > > > So if its using a plain file, then when snapshotting VMs we have
to > > do full copies of the file and keep them all around in sync with > > the disk snapshots. By not having this functionality in QEMU
we don't > > immediately have a way to use qcow2 for the vTPM file backing
store > > to deal with snapshot management. The vTPM needs around snapshotting > > feel fairly similar to the NVRAM needs, so it would be desiralbe
to > > have a ability to do a consistent thing for both. > > The plain file serves as the current state of the TPM. In case of
> migration, suspend, snapshotting, the vTPM state blobs are retrieved > from the vTPM using ioctls and in case of a snapshot they are > written into the QCoW2. Upon resume the state blobs are set in the
> vTPM. I is working as it is.
There is one issue in case of resume of a snapshot.
If the permanent state of the TPM is modified during snapshotting, like
ownership is taken of the TPM, the state, including the owner password,
is written into the plain file. Then the VM is shut down. Once it is restarted
(not a resume from a snapshot), the TPM's state will be relected by what
was done during the run of that snapshot. So this is likely undesirable.
Now the only way around this seems to be that one needs to know the reason
for why the state blobs were pushed into the vTPM. In case of a snapshot,
the writing of the permanent state into a file may need to be suppressed,
while on a VM resume and resume from migration operation it needs to be
written into the TPM's state file.