Stefan Berger/Watson/IBM wrote on 01/21/2016 07:31:10 AM:

> 
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote on 01/21/2016 
> 06:40:35 AM:
> > 
> > > 
> > > 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.

Following tests that I have done (again, on the virt-manager level) the 
above in 3) is not correct. Instead the following seems to be what is 
happening and with that the current vTPM implementation is correct as 
well:

3) The VM is run again and the VM image is in state VM-B (!) and the vTPM 
is also in state vTPM-B from running 2).

Following the run of a VM snapshot, the next time the VM will be started, 
the VM image will in the state when that snapshort terminated. Following 
this, the vTPM's (permanent) state can always be written into the same 
file. 

Regards,
   Stefan