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

[James Bottomley]

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.

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

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

James