qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM
Date: Thu, 21 Jan 2016 11:40:35 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

* 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?

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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]