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
