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.
