In TDX guest, attestation is used to verify the trustworthiness of a TDBefore provisioning secrets to the TD.
to other entities before making any secure communication.
One usage example is, when a TD guest uses encrypted drive and the"The key server can use attestation to verify TD's trustworthiness and release
decryption keys required to access the drive are stored in a secure
3rd party keyserver, TD guest can use the quote generated via the
attestation process to prove its trustworthiness with keyserver and
get access to the storage keys.
the decryption keys to the TD".
It is the key server who starts the attestation request, but not the TD.
General steps involved in attestation process are,Let's separate TDREPORT generation and Quote generation, and get rid of details
1. TD guest generates the TDREPORT that contains version information
about the Intel TDX module, measurement of the TD, along with a
2. TD guest shares the TDREPORT with TD host via GetQuote hypercall
which is used by the host to generate a quote via quoting
3. Quote generation completion notification is sent to TD OS via
callback interrupt vector configured by TD using
4. After receiving the generated TDQUOTE, a remote verifier can be
used to verify the quote and confirm the trustworthiness of the
of how to get Quote part for now. Detail of GetQuote belongs to the patch which
implements it. Here I think we should focus on explaining why we need such a
basic driver to allow userspace to get the TDREPORT.
Below is for your reference:
The attestation process consists of two steps: TDREPORT generation and Quote
generation. TDREPORT (TDREPORT_STRUCT) is a fixed-size data structure generated
by the TDX module to contain the TD-specific informatin (such as TD
measurements), platform information such as the security version of the platform
and the TDX module and the MAC to protect the integrity of the TDREPORT. TD
kernel uses TDCALL[TDG.MR.REPORT] to get the TDREPORT from the TDX module. A
user-provided 64-Byte REPORTDATA is used as input and included in the TDREPORT.
Typically it can be some nonce provided by attestation service so the TDREPORT
can be verified uniquely.
TDREPORT can only be verified locally as the MAC key is bound to the platform.
TDX attestation leverages Intel SGX Quote Enclave (QE) to verify the TDREPORT
locally and convert it to a remote verifiable Quote to support remote
attestation of the TDREPORT. After getting the TDREPORT, the second step of
attestation process is to send the TDREPORT to QE to generate the Quote.
How is the QE, or Quote Generation Service (QGS) in general, implemented and
deployed is implementation specific. As a result, how to send the TDREPORT to
QE/QGS also depends on QE/QGS implementation and the deployment. TDX doesn't
support SGX inside a TD, so the QE/QGS can be deployed in the host, or inside a
dedicated legacy VM.
A typical implementation is TD userspace attestation software gets the TDREPORT
from TD kernel, sends it to QE/QGS, and QE/QGS returns the Quote. The data and
data format that TD userspace attestation software sends to the QE/QGS is also
implementation specific, but not necessarily just the raw TDREPORT. TD
attestation software can use any available communication channel to talk to
QE/QGS, such as using vsock and tcp/ip.
To support the case that those communication channels are not directly available
to the TD, TDX also defines TDVMCALLs to allow TD to use TDVMCALL to ask VMM to
help with sending the TDREPORT and receiving the Quote. This support is
documented in the GHCI spec "5.4 TD attestation".
Implement a basic attestation driver to allow TD userspace to get the TDREPORT
so the attestation software can send it to the QE to generate a Quote for remote
More details on above mentioned steps can be found in TDX Guest-Host
Communication Interface (GHCI) for Intel TDX 1.0, section titled
To allow the attestation agent (user application) to implement this
feature, add an IOCTL interface to get TDREPORT and TDQUOTE from the
user space. Since attestation agent can also use methods like vosck or
TCP/IP to get the TDQUOTE, adding an IOCTL interface for it is an
optional feature. So to simplify the driver, first add support for
TDX_CMD_GET_TDREPORT IOCTL. Support for TDQUOTE IOCTL will be added by
TDREPORT can be generated by sending a TDCALL with leaf ID as 0x04.
More details about the TDREPORT TDCALL can be found in Intel Trust
Domain Extensions (Intel TDX) Module specification, section titled
"TDG.MR.REPORT Leaf". Add a wrapper function (tdx_mcall_tdreport())
to get the TDREPORT from the TDX Module. This API will be used by the
interface driver to request for TDREPORT.
Also note that explicit access permissions are not enforced in this
driver because the quote and measurements are not a secret. However
the access permissions of the device node can be used to set any
desired access policy. The udev default is usually root access