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

[Stefan Berger <stefanb@linux.ibm.com>]

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
>