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

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

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

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

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

   Stefan

> 
> James
>