[ add David, Brijesh, and Atish] Kuppuswamy Sathyanarayanan wrote: > In TDX guest, the second stage of the attestation process is Quote > generation. This process is required to convert the locally generated > TDREPORT into a remotely verifiable Quote. It involves sending the > TDREPORT data to a Quoting Enclave (QE) which will verify the > integrity of the TDREPORT and sign it with an attestation key. > > Intel's TDX attestation driver exposes TDX_CMD_GET_QUOTE IOCTL to > allow the user agent to get the TD Quote. > > Add a kernel selftest module to verify the Quote generation feature. > > TD Quote generation involves following steps: > > * Get the TDREPORT data using TDX_CMD_GET_REPORT IOCTL. > * Embed the TDREPORT data in quote buffer and request for quote > generation via TDX_CMD_GET_QUOTE IOCTL request. > * Upon completion of the GetQuote request, check for non zero value > in the status field of Quote header to make sure the generated > quote is valid. What this cover letter does not say is that this is adding another instance of the similar pattern as SNP_GET_REPORT. Linux is best served when multiple vendors trying to do similar operations are brought together behind a common ABI. We see this in the history of wrangling SCSI vendors behind common interfaces. Now multiple confidential computing vendors trying to develop similar flows with differentiated formats where that differentiation need not leak over the ABI boundary. My observation of SNP_GET_REPORT and TDX_CMD_GET_REPORT is that they are both passing blobs across the user/kernel and platform/kernel boundary for the purposes of unlocking other resources. To me that is a flow that the Keys subsystem has infrastructure to handle. It has the concept of upcalls and asynchronous population of blobs by handles and mechanisms to protect and cache those communications. Linux / the Keys subsystem could benefit from the enhancements it would need to cover these 2 cases. Specifically, the benefit that when ARM and RISC-V arrive with similar communications with platform TSMs (Trusted Security Module) they can build upon the same infrastructure. David, am I reaching with that association? My strawman mapping of TDX_CMD_GET_QUOTE to request_key() is something like: request_key(coco_quote, "description", "<uuencoded tdreport>") Where this is a common key_type for all vendors, but the description and arguments have room for vendor differentiation when doing the upcall to the platform TSM, but userspace never needs to contend with the different vendor formats, that is all handled internally to the kernel. At this point I am just looking for confirmation that the "every vendor invent a new character device + ioctl" does not scale and a deeper conversation is needed. Keys is a plausible solution to that ABI proliferation problem.
