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

["Daniel P. Berrangé" <berrange@redhat.com>]

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.

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