* Stefan Berger (stef...@us.ibm.com) wrote: > Stefan Berger/Watson/IBM wrote on 01/20/2016 02:51:58 PM: > > > "Daniel P. Berrange" <berra...@redhat.com> 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" <berra...@redhat.com> 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? Dave > > Stefan > > > > > Stefan > > > > > > > > > > Regards, > > > Daniel > > > -- > > > |: http://berrange.com -o- > http://www.flickr.com/photos/dberrange/:| > > > |: http://libvirt.org -o- > http://virt-manager.org:| > > > |: http://autobuild.org -o- > http://search.cpan.org/~danberr/:| > > > |: http://entangle-photo.org -o- > http://live.gnome.org/gtk-vnc:| > > > > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK