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

[Stefan Berger]

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.


Regards,
   Stefan

> With regards,
> Daniel