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

[Daniel P . Berrangé]

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
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.

QEMU exposes enough functionality to enable a mgmt app / admin user to
achieve all of 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.

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 :|