[svsm-devel] vTPM service attestation format update

[Dionna Amalie Glaze]

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

Now we're talking about changing the attestation service protocol, not
the vTPM protocol.
We can't change the operation structure of SVSM_ATTEST_SINGLE_SERVICE,
so we need to add SVSM_ATTEST_SINGLE_SERVICE2 and tell the core query
protocol that it's only available at version 2.

The register calling convention is the same, except the operation
structure is longer and uses Linux ABI extension guidelines of using
prior version's behavior when new fields are zero.

Take all of Table 13: Attest Single Service Operation and add

Table 13: Attest Single Service2 Operation
| Byte   Offset | Size (Bytes) |Alignment (Bytes) | Meaning |
...
> | 0x058           |                  4 |                             | The version of the service selection structure for the requested service |
> | 0x05C           |                  2 |                             | The TPMI_ALG_HASH for the digest algorithm to use for the selection structure digest included in the service manifest |
> | 0x05E           |                  2 |                             | RESERVED—MBZ |
> | 0x060           |                  8 |                     4 KB | gPA of the service attestation selector structure |

The same spiel as attest single service follows, but with added text

> If any value starting at 0x58, 0x5C, 0x5E, or 0x60 is 0, they all must be zero, otherwise the call will return SVSM_ERR_INVALID_PARAMETER.
> If the service does not support the TPM_ALG_ID and it is non-zero, the call will return SVSM_ERR_INVALID_PARAMETER.
> If the service is unable to parse the attestation selector structure, the call will return SVSM_ERR_INVALID_PARAMETER.
> No service may use a zero-length attestation selector structure.

Then the "descriptive manifest" changes to include a header

> The service will produce a descriptive manifest in a service-defined format with a required header.
> If the TPM_ALG_ID is 0, the header is empty, otherwise, the manifest is of the form
>
> | Byte offset | Size (bytes) | Meaning |
> | 0x000        |            Variable | TPMT_HA of the selection context |
> | Size(TMPT_HA) |            Variable | The service-specific service manifest |
>
> The selection context is a structure
>
> | Byte offset | Size (bytes) | Meaning |
> | 0x000        |           16 | Service GUID in UUID 4122 network byte order  |
> | 0x010        |             4 | The requested manifest version in little endian    |
> | 0x010        |             4 | The service selection version in little endian    |
> | 0x018        |             8 | The magic number 0x324D5353 |
> | 0x020        | Variable | The service-specific selector structure |
>
> The vTPM protocol may respond to a selector version 1 structure
>
> | Byte offset | Size (bytes) | Meaning |
> | 0x000        |                  2 | Selection kind tag. If 0, then the selector is a TPM_HANDLE for an asymmetric primary key |
> | 0x002        |                  0 | Reserved—MBZ |
> | 0x004        |      size[tag] | If the tag is 0, then size 4 TPM_HANDLE. |
>
> If the vTPM finds that the handle is not for an asymmetric primary key, then the call returns SVSM_ERR_INVALID_PARAMETER.
> Otherwise, the service manifest is the TPMT_PUBLIC of the selected key.

The selection context is there to disambiguate any raw outputs from
different services at different versions.

Meanwhile, if we're going to do weird things, we should have clear
documentation and get some earmarked NV index ranges for Confidential
Computing vTPMs, no?
We ought to make the weird EK template we want accessible in a
specified NV index.
We can get a reserved range of handles by proposing changes to have
the CCC own a range of 64 handles.
https://trustedcomputinggroup.org/wp-content/uploads/Registry-of-Reserved-TPM-2.0-Handles-and-Localities-Version-1.2-Revision-1.00_pub.pdf

I do see that the EK credential profile has B.4.5.3 Table 13 "default
EK template for ECC Signing", so sign = 1 is acceptable for an EK.
There's also reserved NV indices for the automotive industry that
allow for signing EKs, but the Automotive-Thin profile does not make
use of any sign = 1 object attributes for EKs. The referenced
"Automotive-rich" profile doesn't exist.

I notice that Google Cloud's vTPM uses its own NV index for a
non-standard EK template at index 0x1c10000 that we're just kind of...
squatting on. I should work with the TCG to sort that out.








>


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