Dan Williams wrote:
Kuppuswamy Sathyanarayanan wrote:
Hi All,
In TDX guest, the attestation process is used to verify the TDX guest trustworthiness to other entities before provisioning secrets to the guest.
The TDX guest attestation process consists of two steps:
- TDREPORT generation
- Quote generation.
The First step (TDREPORT generation) involves getting the TDX guest measurement data in the format of TDREPORT which is further used to validate the authenticity of the TDX guest. The second step involves sending the TDREPORT to a Quoting Enclave (QE) server to generate a remotely verifiable Quote. TDREPORT by design can only be verified on the local platform. To support remote verification of the TDREPORT, TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT locally and convert it to a remotely verifiable Quote. Although attestation software can use communication methods like TCP/IP or vsock to send the TDREPORT to QE, not all platforms support these communication models. So TDX GHCI specification [1] defines a method for Quote generation via hypercalls. Please check the discussion from Google [2] and Alibaba [3] which clarifies the need for hypercall based Quote generation support. This patch set adds this support.
Support for TDREPORT generation already exists in the TDX guest driver. This patchset extends the same driver to add the Quote generation support.
I missed that the TDREPORT ioctl() and this character device are already upstream. The TDREPORT ioctl() if it is only needed for quote generation seems a waste because it just retrieves a blob that needs to be turned around and injected back into the kernel to generate a quote.
An ABI wants to care about the abstractions around what the hardware mechanism enables. The TD quote is not even at the end of that chain of what the ABI needs to offer. The guest wants to use the TD quote to access / unlock other resources, just like the SEV report is used to "...provide the VM with secrets, such as a disk decryption key, or other keys required for operation".
That's where the ABI line needs to be drawn. I.e. for the guest to be able to request the distributions of keys to unlock resources by a key-type and key-descriptor. Enable userspace to interrogate an attestation object without blobs needing to traverse the kernel. If the remote service needs more than just a blob and signature to validate the state of the guest then provide faclity to interrogate that property of quote / report in a common way versus the ABI risk of conveying vendor specific binary data formats in the kernel ABI.
A proposal for how this space moves forward:
1/ Stop accepting new arch specific ioctls in this space and revert the Intel TDREPORT ioctl if its only reason for existing is "quote" generation.
2/ Define a container format / envelope for platform-provided attestation evidence.
The observation here is that although it is too late to unify the evidence formats across vendors, they appear to share the common form of a blob with an ECDSA signature. That reduces the minimum viable attestation service to something that can generically verify an evidence-blob signature.
3/ Define a key-description format that considers a superset of the platform needs. For example a 'privelege-level' concept can map to 'vmpl' on AMD, but be ignored for now for Intel.
4/ For in progress enabling concepts like runtime measurement registers, look to reuse / abstract that behind the Keys subsystem existing support for managing TPM PCRs.
5/ Deprecate the multiple arch specific attestation ioctl interfaces in favor of this unified conveyance method.