On Wed, 2023-03-22 at 17:47 +0000, Dr. David Alan Gilbert wrote: [...] > > I think this might need to jump back to the vTPM protocol thread > > since this is about COCONUT, but I'm worried we're talking about > > AMD-specific long-term formats when perhaps the trusted computing > > group should be widening its scope to how a TPM should be > > virtualized. I appreciate that we're attempting to solve the > > problem in the short term, and certainly the SVSM will need > > attestation capabilities, but the linking to the TPM is dicey > > without that conversation with TCG, IMHO. > > Some standardisation of the link between the vTPM and the underlying > CoCo hardware would be great; there's at least 2 or 3 CoCo linked > vTPMs already and I don't think they're sharing any idea of that. Well, for SNP, it's easy: the VMPL0 labelled attestation report proves the SVSM and other components including OVMF and vTPM code implementation. We insert a hash of the manufactured EK into the report and that gives proof from the trusted SVSM of the EK belonging to the vTPM (essentially binding the vTPM to the VM). The same thing would work for other CoCo VM environments. If we do ephemeral vTPMs, the binding is one time and there's no persistent state security issue, so the SVSM-vTPM attestation is all you need to begin trusting the vTPM measurements. > Whether it's TCG I'm not sure; It doesn't seem to me to make sense > for them to specify the flow to bring the vTPM up or the details of > the underlying CoCo's attestation; but standardising how the two > processes are tied together might be possible. I think the TCG is probably not going to touch that because how you attest the code that will run as the SVSM and vTPM is very specific to each CoCo implementation. However, they all provide a user data like field which allows you to add information from the to be verified as trusted SVSM, so you can use it for the EK, which is pretty identical to the above proposal. James
