Re: SVSM draft specification

On Mon, 2025-06-30 at 11:36 -0500, Tom Lendacky wrote:
> Attached is a draft specification with the following changes:
> 
>   - New single service extended attestation request
>   - vTPM service update for single service extended attestation
> request

I don't think any of the flags in the vTPM single service attestation
are a good idea

   1. Whether non volatile UEFI variables have backing or not is
      nothing to do with the TPM service ... there should be a UEFI
      variable service that indicates this (when it's even available).
   2. How does the vTPM or even the SVSM know if the system is secure
      booted?  That's the province of OVMF to enforce.  The SVSM can
      deduce it possibly from the state of the variables, but on
      security separation grounds the vTPM service should *not* be
      accessing the UEFI variable service.
   3. Preventing updates to db/dbx will require code changes to the
      reference implementation ... that's always a bad idea since it
      moves us away from what the TCG publishes and means we have to
      keep an out of tree patch.  What's the point of it anyway?  The
      way to ensure the guest can't update db/dbx is what we have today
      for physical systems: not knowing the private key in KEK.
Regards,

James