On Sun, Jun 25, 2023 at 9:32 PM Dan Williams dan.j.williams@intel.com wrote:
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:
- TDREPORT generation
- 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.
I agree a unified ABI across vendors would be ideal in the long term. However, it sounds like a non-trivial task and could take quite some time to achieve. Given there's already an AMD equivalent approach upstreamed, can we also allow this TDVMCALL patch as an intermediate step to unblock various TDX attestation user cases while targeting unified ABI? The TDVMCALL here is quite isolated and serves a very specific purpose, it should be very low risk to other kernel features and easy to be reverted in the future.