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

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.

James


Reply via email to