> + > +At TDX guest runtime, the Intel TDX module reuses the Intel SGX attestation > +infrastructure to provide support for attesting to these measurements as > +described below. The above paragraph isn't right. The Intel TDX module itself doesn't use anything about SGX (perhaps except using the key to generate the MAC for the TDREPORT, but it certainly doesn't use "SGX infrastructure" for sure). Even the new ENCLU leaf used to verify the TDREPORT is not part of the TDX module -- it's an extension to SGX to support TDX attestation. Also, conceptually, only the verification service can truly _attest_ something. The SGX software stack running on the machine that hosts TDX guests doesn't actually _attest_ anything. It only can _generate_ something (Quote) that can be attested. In below you already mentioned "TDX leverages Intel SGX Quote (should be Quoting I think) Enclave to ...". I don't think this paragraph is even necessary and you can just delete it. If you really want to say, I think one simple sentence like "TDX leverages SGX to support attestation" is enough. > + > +The attestation process consists of two steps: TDREPORT generation and > +Quote generation. > + > +TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT) > +from the TDX module. TDREPORT is a fixed-size data structure generated by > +the TDX module which contains guest-specific information (such as build > +and boot measurements), platform security version, and the MAC to protect > +the integrity of the TDREPORT. > + > +After getting the TDREPORT, the second step of the attestation process > +is to send it to the QE to generate the Quote. TDREPORT by design can only > +be verified on local platform as the MAC key is bound to the platform. To > +support remote verification of the TDREPORT, TDX leverages Intel SGX Quote > +Enclave (QE) to verify the TDREPORT locally and convert it to a remote > +verifiable Quote. Method of sending TDREPORT to QE is implemenentation > +specific. Attestation software can choose whatever communication channel > +available (i.e. vsock or hypercall) to send the TDREPORT to QE and receive > +the Quote. > + > +To allow userspace attestation agent get the TDREPORT, TDX guest driver ^ to get > +exposes an IOCTL (TDX_CMD_GET_REPORT) interface via /dev/tdx-guest misc > +device. > + > +TDX Guest driver > +================ > + > +The TDX guest driver exposes IOCTL interfaces via /dev/tdx-guest misc > +device to allow user space to get certain TDX guest specific details > +(like attestation report, attestation quote or storage keys, etc). Only TDX_CMD_GET_REPORT is supported now. Whether GetQuote TDVMCALL should be supported, or how should it be supported is unknown now. Not to mention "get the storage keys". I don't think you should put anything here now except "allow userspace to get TDREPORT". > + > +In this section, for each supported IOCTL, following information is > +provided along with generic description. > + > +:Input parameters: Parameters passed to the IOCTL and related details. > +:Output: Details about output data and return value (with details > + about the non common error values). > + > +TDX_CMD_GET_REPORT > +------------------ > + > +:Input parameters: struct tdx_report_req > +:Output: Upon successful execution, TDREPORT data is copied to > + tdx_report_req.tdreport and returns 0 or returns > + -EIO on TDCALL failure and standard error number on > + other common failures. > + > +The TDX_CMD_GET_REPORT IOCTL can be used by the attestation software to > +get the TDX guest measurements data (with few other info) in the format > +of TDREPORT_STRUCT. > IMHO "to get the TDREPORT" is enough. You already used TDREPORT in many places in this documentation (and in this series), and you have already explained it. With above (at least errors) fixed: Acked-by: Kai Huang <kai.huang@xxxxxxxxx> -- Thanks, -Kai
