Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM

[Stefan Berger]

"Dr. David Alan Gilbert" <address@hidden>
wrote on 01/21/2016 06:40:35 AM:

> 
> * Stefan Berger (address@hidden) wrote:
> > 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.
> 
> I don't understand that; are you saying that the ioctl's dont provide
all
> the information that's included in the state file?

No. Running a snapshot does not change the state of
the VM image unless one takes another snapshot. The vTPM has to be behave
the same way, meaning that the state of the vTPM must not be overwritten
while in a snapshot. However, the vTPM needs to know that it's running
a snapshot whose state is 'volatile'.

Example:  
1) A VM is run and VM image is in state VM-A and vTPM
is in state vTPM-A. The VM is shut down and VM is in state VM-A and vTPM
is in state vTPM-A.

2) The VM runs a snapshot and VM image is in state
VM-B and vTPM is in state B. The user takes ownership of the vTPM, which
puts the vTPM into state vTPM-B2. VM is shut down and with that all VM
image state is discarded. Also the VTPM's state needs to be discarded.

3) The VM is run again and the VM image is in state
VM-A and the vTPM must be in state vTPM-A from 1). However, at the moment
the vTPM wold be in state vTPM-B2 from the last run of the snapshot since
the state was written into the vTPM's state file.

The way around the problem in 3) stemming from 2)
is writing the vTPM state (which is kept in a file) into a differently
named file while running a snapshot. However, QEMU needs to tell the vTPM
that it's running a snapshot and the state is to be treated as volatile.
A flag that conveys 'you're running a snapshot' while setting the device
state would be enough. Though currently the function that triggers the
setting of device state doesn't get that in a flag. So there would have
to be a function like 'flag = qemu_doing_snapshot()' and pass that flag
to the vTPM. Maybe it already exists.

    Stefan