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

[Sathyanarayanan Kuppuswamy]

Hi Kai,

On 4/24/22 10:44 PM, Kai Huang wrote:
> > In TDX guest, attestation is used to verify the trustworthiness of a TD
> > to other entities before making any secure communication.
> Before provisioning secrets to the TD.
>
> > One usage example is, when a TD guest uses encrypted drive and the
> > 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 key server can use attestation to verify TD's trustworthiness and release
> 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,
> >
> >    1. TD guest generates the TDREPORT that contains version information
> >       about the Intel TDX module, measurement of the TD, along with a
> >       TD-specified nonce.
> >    2. TD guest shares the TDREPORT with TD host via GetQuote hypercall
> >       which is used by the host to generate a quote via quoting
> >       enclave (QE).
> >    3. Quote generation completion notification is sent to TD OS via
> >       callback interrupt vector configured by TD using
> >       SetupEventNotifyInterrupt hypercall.
> >    4. After receiving the generated TDQUOTE, a remote verifier can be
> >       used to verify the quote and confirm the trustworthiness of the
> >       TD.
> Let's separate TDREPORT generation and Quote generation, and get rid of details
> 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
> verification.
> "
>
>
> >       
> > More details on above mentioned steps can be found in TDX Guest-Host
> > Communication Interface (GHCI) for Intel TDX 1.0, section titled
> > "TD attestation".
> >
> > 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
> > follow-on patches.
> >
> > 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
> > only.

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

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".

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.

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
only.




--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer