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

[Stefan Berger]

On 12/15/22 15:07, James Bottomley wrote:
> On Thu, 2022-12-15 at 14:57 -0500, Stefan Berger wrote:
> > On 12/15/22 14:40, James Bottomley wrote:
> > > On Thu, 2022-12-15 at 14:35 -0500, Stefan Berger wrote:
> [...]
> > > > You should also add a description to docs/specs/tpm.rst.
> > >
> > > Description of what?  It functions exactly like passthrough on
> >
> > Please describe all the scenarios so that someone else can repeat
> > them when trying out **your** device.
> >
> > There are sections describing how things for swtpm and you should add
> > how things work for the mssim TPM.
> >
> > https://github.com/qemu/qemu/blob/master/docs/specs/tpm.rst#the-qemu-tpm-emulator-device
> > https://github.com/qemu/qemu/blob/master/docs/specs/tpm.rst#migration-with-the-tpm-emulator
>
> The passthrough snapshot/restore isn't described there either.  This

Forget about passthrough, rather compare it to swtpm.

> behaves exactly the same in that it's caveat emptor.  If something
> happens in the interim to upset the TPM state then the restore will
> have unexpected effects due to the externally changed TPM state.  This
> is actually a feature: I'm checking our interposer defences by doing
> external state manipulation.
>
> > > migration.  Since the TPM state is retained in the server a
> > > reconnection just brings everything back to where it was.
> >
> > So it's remote. And the ports are always open and someone can just
> > connect to the open ports and power cycle the device?
>
> in the same way as you can power off the hardware and have issues with
> a passthrough TPM on vm restore, yes.

I don't thinkyou should compare the mssim TPM with passthrough but rather with 
swtpm emulator + tpm_emulator backend. That's a much better comparison.

> > This may not be the most important scenario but nevertheless I
> > wouldn't want to deal with bug reports if someone does 'VM
> > snapshotting' -- how this is correctly handled would be of interest.
>
> I'd rather say nothing, like passthrough, then there are no
> expectations beyond it might work if you know what you're doing.  I

Why do we need this device then if it doesn't handle migration scenarios in the 
same or better way than swtpm + tpm_emulator backends already do?

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

   Stefan

> James