[svsm-devel] vTPM service attestation format update

[Dionna Amalie Glaze]

> 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")

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


--
-Dionna Glaze, PhD, CISSP, CCSP (she/her)