[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
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, (continued)
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, Xu, Quan, 2016/01/04
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, Xu, Quan, 2016/01/19
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, Daniel P. Berrange, 2016/01/20
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, Stefan Berger, 2016/01/20
- Message not available
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, Daniel P. Berrange, 2016/01/20
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, Stefan Berger, 2016/01/20
- Message not available
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, Stefan Berger, 2016/01/20
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM,
Dr. David Alan Gilbert <=
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, Stefan Berger, 2016/01/21
- Message not available
- Re: [Qemu-devel] [PATCH v5 0/4] Extend TPM support with a QEMU-external TPM, Dr. David Alan Gilbert, 2016/01/21