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: > > > > 1. TDREPORT generation > > 2. 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.
