Re: [PATCH v4 1/3] x86/tdx: Add TDX Guest attestation interface driver

From: Sathyanarayanan Kuppuswamy
Date: Wed Apr 27 2022 - 10:09:19 EST

On 4/26/22 9:28 PM, Kai Huang wrote:

How about the following summary? It includes important notes mentioned
by you and some more driver info.

Yes fine to me, except minor comments below:

x86/tdx: Add TDX Guest attestation interface driver

In TDX guest, attestation is used to verify the trustworthiness of a TD
to other entities before provisioning secrets to the TD.

One usage example is, when a TD guest uses encrypted drive and if the
decryption keys required to access the drive are stored in a secure 3rd
party key server, the key server can use attestation to verify TD's
trustworthiness and release the decryption keys to the TD.

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 which contains TD-specific information (such as TD
measurements), platform security version, and the MAC to protect the
integrity of the TDREPORT. The 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. More details about TDREPORT can be found in
Intel TDX Module specification, section titled "TDG.MR.REPORT Leaf".

After getting the TDREPORT, the second step of the attestation process
is to send the TDREPORT to Quoting Enclave (QE) or Quote Generation
Service (QGS) to generate the Quote. However, the method of sending the
TDREPORT to QE/QGS, communication channel used and data format used is
specific to the implementation of QE/QGS.

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. 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 TDVMCALL
(TDG.VP.VMCALL<GetQuote>) to allow TD to ask VMM to help with sending
the TDREPORT and receiving the Quote. This support is documented in the
GHCI spec section titled "5.4 TD attestation".

I intentionally omitted to mention TDG.VP.VMCALL<GetQuote> as I personally
believe there are still couple issues around GetQuote that we haven't discussed
thoroughly (timeout, etc). I am still considering whether we should change GHCI
to use TDG.VP.VMCALL<Service> defined in GHCI 1.5 for attestation. And the name
of TDVMCALL doesn't actually matter here, so I think we don't need to mention
GetQuote here but just say we have TDVMCALLs for that.


Implement a basic attestation driver to allow TD userspace to get the
TDREPORT, which is sent to QE by the attestation software to generate
a Quote for remote verification. 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.

I don't think you need to mention tdx_mcall_tdreport().

Ok. Will remove it.

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

Sathyanarayanan Kuppuswamy
Linux Kernel Developer