fitzthum
commented
3 weeks ago At the moment our reference value provider is simplistic. It is a key-value store that is provisioned by the operator of the KBS. We are on the verge of implementing something more sophisticated (hopefully), so your issue is well-timed.
Two things that we have discussed are adopting a more expressive format for reference values (potentially CoRIM) and introducing a mechanism to share contextual values such as a workload class between host, guest, workload, relying party, verifier, etc. I think this is related to what you mention.
We have not discussed sharing reference values directly from the guest/worker, but this seems like it could be a reasonable thing to do. You might be able to implement something like this with init-data and a sophisticatd Rego policy. Otherwise we would probably need to think about extending the KBS protocol. I'd need to think more about how to support this.
Another approach would be to add your extraction logic to the RVPS such that the GCE manifest thing could be consumed directly. This probably wouldn't help you push reference values from a worker node to the verifier, but it would at least allow the RVPS to consume the reference values. In theory the RVPS should be able to consume reference values from many different formats, so this could be a natural fit. On the other hand, we're not yet sure how to best handle these reference values internally so there is still some thinking needed here.
deeglaze
Xynnn007
The IETF RATS working group is standardizing a Conceptual Message Wrapper format that allows an attester to bundle different "conceptual messages" to send along the attestation conversation.
Concepts include evidence, endorsement, reference values, and attestation results.
The TCG PC Client Platform Firmware Profile allows for an event log to include unmeasured events to point the verifier to the signed reference measurements of the firmware through an event named after NIST Special Publication 800-155. I've written the extraction logic that can interpret raw data, UEFI variable pointers, and URI pointers. I haven't added UEFI local device path support.
It's often beneficial for an attester to send along any node-cached reference values since there could be updates that haven't made their way to the RVPS before attestation, but are signed by a trusted authority.
The SP800155 event is but one pathway to provide reference measurements. For VMs that don't have mount efivarfs for whatever reason, the AMD extended guest request ABI allows for the host to provide extra data with GUIDed entries of their own (e.g., https://github.com/google/gce-tcb-verifier/blob/main/sev/endorsement.go#L31)
The format I've proposed for signed firmware measurements is a couple years old at this point, and I've been working with the IETF to get CoRIM to a better state for us to use, so let me know if Trustee would accept any GCE-specific logic for interpreting our signed protobuf thing or if you'll wait until we deploy CoRIMs.
We haven't had much of an industry discussion on what CoRIM profile we should use for SEV-SNP and TDX anyway, so with that format comes further interpretation that's still undecided.