Re: [PATCH v3 0/3] TDX Guest Quote generation support

[Dan Williams]

Sathyanarayanan Kuppuswamy wrote:
> 
> 
> On 6/23/23 9:05 PM, Dan Williams wrote:
> > Kuppuswamy Sathyanarayanan wrote:
> >> Hi All,
> >>
> >> In TDX guest, the attestation process is used to verify the TDX guest
> >> trustworthiness to other entities before provisioning secrets to the
> >> guest.
> >>
> >> The TDX guest attestation process consists of two steps:
> >>
> >> 1. TDREPORT generation
> >> 2. Quote generation.
> >>
> >> The First step (TDREPORT generation) involves getting the TDX guest
> >> measurement data in the format of TDREPORT which is further used to
> >> validate the authenticity of the TDX guest. The second step involves
> >> sending the TDREPORT to a Quoting Enclave (QE) server to generate a
> >> remotely verifiable Quote. TDREPORT by design can only be verified on
> >> the local platform. To support remote verification of the TDREPORT,
> >> TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT
> >> locally and convert it to a remotely verifiable Quote. Although
> >> attestation software can use communication methods like TCP/IP or
> >> vsock to send the TDREPORT to QE, not all platforms support these
> >> communication models. So TDX GHCI specification [1] defines a method
> >> for Quote generation via hypercalls. Please check the discussion from
> >> Google [2] and Alibaba [3] which clarifies the need for hypercall based
> >> Quote generation support. This patch set adds this support.
> >>
> >> Support for TDREPORT generation already exists in the TDX guest driver. 
> >> This patchset extends the same driver to add the Quote generation
> >> support.
> > 
> > I missed that the TDREPORT ioctl() and this character device are already
> > upstream. The TDREPORT ioctl() if it is only needed for quote generation
> > seems a waste because it just retrieves a blob that needs to be turned
> > around and injected back into the kernel to generate a quote.
> 
> Although the end goal is to generate the quote, the method the user chooses to
> achieve it may differ for a variety of reasons. In this case, we're trying to
> support the use case where the user will use methods like TCP/IP or vsock to
> generate the Quote. They can use the GET_REPORT IOCTL to get the TDREPORT and
> send it to the quoting enclave via the above-mentioned methods.  TDVMCALL-based
> quote generation is intended for users who, for a variety of security reasons, do
> not wish to use the methods described above.

This flexibility could be supported with keys if necessary, although I
would want to hear strong reasons not a "variety of reasons" why
everyone cannot use a unified approach. ABI proliferation has a
maintenance cost and a collaboration cost. It is within the kernel
community's right to judge the cost of ABI flexibility and opt for a
constrained implementation if that cost is too high.

What I would ask of those who absolutely cannot support the TDVMCALL
method is to contribute a solution that intercepts the "upcall" to the
platform "guest_attest_ops" and turn it into a typical keys upcall to
userspace that can use the report data with a vsock tunnel.

That way the end result is still the same, a key established with the
TDX Quote evidence contained within a Linux-defined envelope.