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

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

* James Bottomley (jejb@linux.ibm.com) wrote:
> On Mon, 2023-01-09 at 16:59 +0000, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > > On Fri, Dec 16, 2022 at 08:32:44AM -0500, Stefan Berger wrote:
> [...]
> > > > 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.
> 
> It works under limited circumstances ... in fact similar circumstances
> passthrough migration works under,

Well, not that similar - people expect passthrough migration to fail
because, being nailed to a physical servers hardware it's not likely to
migrate; where as you're creating a new virtual thing which people might
imagine is similar to the existing swtpm.  Their imagination might be
wrong and thus you need to say why.

> which is also not documented.  The

Inductive proof that we should have no good documentation doesn't get us
anywhere.

> external MSSIM TPM emulator has to be kept running to preserve the
> state.  If you restart it, the migration will fail.

Document that and we're getting there.

Dave

> James
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK