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

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

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