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

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

On 1/10/23 09:55, James Bottomley wrote:
> On Tue, 2023-01-10 at 09:47 -0500, Stefan Berger wrote:
>> On 1/10/23 09:14, James Bottomley wrote:
>>> On Mon, 2023-01-09 at 16:06 -0500, Stefan Berger wrote:
>>>> On 1/9/23 14:01, Stefan Berger wrote:
>>> [...]
>>>> If you use TPM 2 for attestation then certain TPM 2 state
>>>> migration scenarios may become problematic. One could construct a
>>>> scenario where attestation preceeds some action that requires
>>>> trust to have been established in the system in the preceeding
>>>> attestation step and support for snapshotting the state of the
>>>> TPM 2 could become an issue if I was to wait for the attestation
>>>> to have been concluded and then I quickly restart a different
>>>> snapshot that is not trustworthy and the client proceeds thinking
>>>> that the system is trustworthy (maybe a few SYNs from the client
>>>> went into the void)
>>>
>>> You're over thinking this.  For a non-confidential VM, Migration
>>> gives you a saved image you can always replay from (this is seen as
>>> a feature for fast starts) and if you use the tpm_simulator the TPM
>>> state is stored in the migration image, so you can always roll it
>>> back if you
>>
>> 'How' is it stored in the migration image? Does tpm_simulator marshal
>> and unmarshal the state so that it is carried inside the save image?
>> For the tpm_emulator backend this particular code is here:
>> -
>> https://github.com/qemu/qemu/blob/master/backends/tpm/tpm_emulator.c#L758
>> -
>> https://github.com/qemu/qemu/blob/master/backends/tpm/tpm_emulator.c#L792
> 
> We seem to be going around in circles: your TPM simulator stores the
> TPM state in the migration image, mine keeps it in the external TPM.
> The above paragraph is referring to your simulator.

My simulator is typically called 'swtpm'.


> 
>>> have access to the migration file.  Saving the image state is also
>>> a huge problem because the TPM seeds are in the clear if the
>>> migration image isn't encrypted.  The other big problem is that an
>>> external
>>
>> True. DAC protection of the file versus protection via encryption.
>> Neither really helps against malicious root.
>>
>>> software TPM is always going to give up its state to the service
>>> provider, regardless of migration, so you have to have some trust
>>> in the provider and thus you'd also have to trust them with the
>>> migration replay policy.  For Confidential VMs, this is a bit
>>> different because the vTPM runs in a secure ring inside the
>>> confidential enclave and the secure migration agent ensures that
>>> either migration and startup happen or migration doesn't happen at
>>> all, so for them you don't have to worry about rollback.
>>
>> what is the enclave here? Is it an SGX enclave or is it running
>> somewhere inside the address space of the VM?
> 
> The only current one we're playing with is the SEV-SNP SVSM vTPM which
> runs the TPM in VMPL0.

And how is this related to this PR?

> 
>>>
>>> Provided you can trust the vTPM provider, having external state not
>>> stored in the migration image has the potential actually to solve
>>> the rollback problem because you could keep the TPM clock running
>>> and potentially increase the reset count, so migrations would show
>>> up in TPM quotes and you don't have control of the state of the
>>> vTPM to replay it.
>>
>> I just don't see how you do that and prevent scenarios where VM A is
>> suspended and then the tpm_simulator just sits there with
>> the state and one resumes VM B with the state.
> 
> You can't with your TPM simulator because it stores state in the image.
> If the state is external (not stored in the image) then rolling back
> the image doesn't roll back the TPM state.

And resuming VM B with the TPM state of suspend VM A is considered 'good'?

    Stefan

> 
> James
>