Re: [PATCH 2/2] tpm: add backend for mssim

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Fri, Dec 16, 2022 at 08:32:44AM -0500, Stefan Berger wrote:
> > 
> > 
> > On 12/16/22 07:54, Daniel P. Berrangé wrote:
> > > On Fri, Dec 16, 2022 at 07:28:59AM -0500, Stefan Berger wrote:
> > > > 
> > > > 
> > > > On 12/16/22 05:27, Daniel P. Berrangé wrote:
> > > > > On Thu, Dec 15, 2022 at 03:53:43PM -0500, Stefan Berger wrote:
> > > > > > 
> > > > > > 
> > > > > > On 12/15/22 15:30, James Bottomley wrote:
> > > > > > > On Thu, 2022-12-15 at 15:22 -0500, Stefan Berger wrote:
> > > > > > > > On 12/15/22 15:07, James Bottomley wrote:
> > > > > > > [...]
> > > > > > > > > don't really have much interest in the migration use case, but I
> > > > > > > > > knew it should work like the passthrough case, so that's what I
> > > > > > > > > tested.
> > > > > > > > 
> > > > > > > > I think your device needs to block migrations since it doesn't handle
> > > > > > > > all migration scenarios correctly.
> > > > > > > 
> > > > > > > Passthrough doesn't block migrations either, presumably because it can
> > > > > > > also be made to work if you know what you're doing.  I might not be
> > > > > > 
> > > > > > Don't compare it to passthrough, compare it to swtpm. It should
> > > > > > have at least the same features as swtpm or be better, otherwise
> > > > > > I don't see why we need to have the backend device in the upstream
> > > > > > repo.
> > > > > 
> > > > > James has explained multiple times that mssim is a beneficial
> > > > > thing to support, given that it is the reference implementation
> > > > > of TPM2. Requiring the same or greater features than swtpm is
> > > > > an unreasonable thing to demand.
> > > > 
> > > > Nevertheless it needs documentation and has to handle migration
> > > > scenarios either via a blocker or it has to handle them all
> > > > correctly. Since it's supposed to be a TPM running remote you
> > > > had asked for TLS support iirc.
> > > 
> > > If the mssim implmentation doesn't provide TLS itself, then I don't
> > > consider that a blocker on the QEMU side, merely a nice-to-have.
> > > 
> > > With swtpm the control channel is being used to load and store state
> > > during the migration dance. This makes the use of an external process
> > > largely transparent to the user, since QEMU handles all the state
> > > save/load as part of its migration data stream.
> > > 
> > > With mssim there is state save/load co-ordination with QEMU. Instead
> > > whomever/whatever is managing the mssim instance, is responsible for
> > > ensuring it is running with the correct state at the time QEMU does
> > > a vmstate load. If doing a live migration this co-ordination is trivial
> > > if you just use the same mssim instance for both src/dst to connect to.
> > > 
> > > If doing save/store to disk, the user needs to be able to save the mssim
> > > state and load it again later. If doing snapshots and reverting to old
> > 
> > There is no way for storing and loading the *volatile state* of the
> > mssim device.
> > 
> > > snapshots, then again whomever manages mssim needs to be keeping saved
> > > TPM state corresponding to each QEMU snapshot saved, and picking the
> > > right one when restoring to old snapshots.
> > 
> > This doesn't work.
> > Either way, if it's possible it can be documented and shown how this works.
> > 
> > > 
> > > QEMU exposes enough functionality to enable a mgmt app / admin us> achieve all of this.
> > 
> > How do you store the volatile state of this device, like the current
> > state of the PCRs, loaded sessions etc? It doesn't support this.
> > 
> > > 
> > > This is not as seemlessly integrated with swtpm is, but it is still
> > > technically posssible todo the right thing with migration from QEMU's
> > > POV. Whether or not the app/person managing mssim instance actually
> > > does the right thing in practice is not a concern of QEMU. I don't
> > > see a need for a migration blocker here.
> > 
> > I do see it because the *volatile state* cannot be extracted from
> > this device. The state of the PCRs is going to be lost.
> 
> All the objections you're raising are related to the current
> specifics of the implementation of the mssim remote server.
> While valid, this is of no concern to QEMU when deciding whether
> to require a migration blocker on the client side. This is 3rd
> party remote service that should be considered a black box from
> QEMU's POV. It is possible to write a remote server that supports
> the mssim network protocol, and has the ability to serialize
> its state. Whether such an impl exists today or not is separate.

We would normally want an example of a working implementation though
wouldn't we?

So I think it's fair to at least want some documentation; if it can be
documented and works, fine; if it doesn't work, then it needs a blocker.

Dave

> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK