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
