[svsm-devel] vTPM service attestation format update

[James Bottomley]

On Fri, 2025-02-21 at 09:29 -0800, Dionna Amalie Glaze wrote:
> > That's a lot of GUIDs; why not simply define a guid for the
> > additional
> > arguments and then pass them in in TPM form (except probably native
> > endian)?
> > 
> 
> That sure does sound nice, but that will mean either adding a new
> call to the vTPM service so that it changes which EK it reports in
> the service manifest, or to clarify in the service manifest that "the
> endorsement key" refers to the last created primary key on the
> endorsement hierarchy. That could be fine too.
> 
> I will note that in SVSM Revision 1.00 section 8's first table "table
> 14. Attestation Protocol Services" seems like a copy/paste error from
> table 10. It should be "table 14. vTPM protocol services")

Heh, yes, that was pointed out when Tom first produced the current doc
... and several time since.

> > Call ID | First version supported | Name | Function
> >  2 | 2 | SVSM_VTPM_CHOOSE_ATTESTED_EK | Changes service state to
> report the given EK in the service manifest |
> 
> The request structure is the send command request structure
> restricted to create primary on the endorsement hierarchy. Seems
> silly, so I would say no to that.
> 
> If we say the attested EK is the "last created", this increases the
> obligations on persisted data for the vTPM. Not a big problem, but
> just something to be aware of.

Well, you could do that, yes.  However, I was actually thinking of
adding two new attestation guids having a _WITH_ARG suffix that allow
you to pass in an extra pointer and length representing an argument
buffer that the attestation protocol could validate and use.  Thus the
VTPM attestation would choose the current template in the non-_WITH_ARG
case as it does now and validate and perform attestation on the
requested template in the _WITH_ARG case.  For completeness of inputs I
suppose it makes sense that a whole template should actually be passed
in as a TPMT_PUBLIC.

Regards,

James