| Message ID | cover.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | TDX Guest Quote generation support | expand |
Tested-by: Qinkun Bao <qinkun@google.com> Thanks Sathyanarayanan for the new patch! This patch is critical for our use case. We built a guest image with the patch, and verified it works for us, when using a host kernel built with https://github.com/intel/tdx repo. On Sun, May 14, 2023 at 12:24 AM Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> 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. > > Following are the details of the patch set: > > Patch 1/3 -> Adds event notification IRQ support. > Patch 2/3 -> Adds Quote generation support. > Patch 3/3 -> Adds selftest support for Quote generation feature. > > [1] https://cdrdv2.intel.com/v1/dl/getContent/726790, section titled "TDG.VP.VMCALL<GetQuote>". > [2] https://lore.kernel.org/lkml/CAAYXXYxxs2zy_978GJDwKfX5Hud503gPc8=1kQ-+JwG_kA79mg@mail.gmail.com/ > [3] https://lore.kernel.org/lkml/a69faebb-11e8-b386-d591-dbd08330b008@linux.alibaba.com/ > > Kuppuswamy Sathyanarayanan (3): > x86/tdx: Add TDX Guest event notify interrupt support > virt: tdx-guest: Add Quote generation support > selftests/tdx: Test GetQuote TDX attestation feature > > Documentation/virt/coco/tdx-guest.rst | 11 ++ > arch/x86/coco/tdx/tdx.c | 194 +++++++++++++++++++ > arch/x86/include/asm/tdx.h | 8 + > drivers/virt/coco/tdx-guest/tdx-guest.c | 175 ++++++++++++++++- > include/uapi/linux/tdx-guest.h | 44 +++++ > tools/testing/selftests/tdx/tdx_guest_test.c | 65 ++++++- > 6 files changed, 490 insertions(+), 7 deletions(-) > > -- > 2.34.1 >
Hi, On 5/24/23 2:33 PM, Chong Cai wrote: > Tested-by: Qinkun Bao <qinkun@google.com> > > Thanks Sathyanarayanan for the new patch! This patch is critical for > our use case. > We built a guest image with the patch, and verified it works for us, > when using a host kernel built with https://github.com/intel/tdx repo. Qinkun Bao/Chong Cai, thanks for testing it. I really appreciate the help. Dave/Boris, could you please take a look at this patch set? > > On Sun, May 14, 2023 at 12:24 AM Kuppuswamy Sathyanarayanan > <sathyanarayanan.kuppuswamy@linux.intel.com> 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. >> >> Following are the details of the patch set: >> >> Patch 1/3 -> Adds event notification IRQ support. >> Patch 2/3 -> Adds Quote generation support. >> Patch 3/3 -> Adds selftest support for Quote generation feature. >> >> [1] https://cdrdv2.intel.com/v1/dl/getContent/726790, section titled "TDG.VP.VMCALL<GetQuote>". >> [2] https://lore.kernel.org/lkml/CAAYXXYxxs2zy_978GJDwKfX5Hud503gPc8=1kQ-+JwG_kA79mg@mail.gmail.com/ >> [3] https://lore.kernel.org/lkml/a69faebb-11e8-b386-d591-dbd08330b008@linux.alibaba.com/ >> >> Kuppuswamy Sathyanarayanan (3): >> x86/tdx: Add TDX Guest event notify interrupt support >> virt: tdx-guest: Add Quote generation support >> selftests/tdx: Test GetQuote TDX attestation feature >> >> Documentation/virt/coco/tdx-guest.rst | 11 ++ >> arch/x86/coco/tdx/tdx.c | 194 +++++++++++++++++++ >> arch/x86/include/asm/tdx.h | 8 + >> drivers/virt/coco/tdx-guest/tdx-guest.c | 175 ++++++++++++++++- >> include/uapi/linux/tdx-guest.h | 44 +++++ >> tools/testing/selftests/tdx/tdx_guest_test.c | 65 ++++++- >> 6 files changed, 490 insertions(+), 7 deletions(-) >> >> -- >> 2.34.1 >>
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. An ABI wants to care about the abstractions around what the hardware mechanism enables. The TD quote is not even at the end of that chain of what the ABI needs to offer. The guest wants to use the TD quote to access / unlock other resources, just like the SEV report is used to "...provide the VM with secrets, such as a disk decryption key, or other keys required for operation". That's where the ABI line needs to be drawn. I.e. for the guest to be able to request the distributions of keys to unlock resources by a key-type and key-descriptor. Enable userspace to interrogate an attestation object without blobs needing to traverse the kernel. If the remote service needs more than just a blob and signature to validate the state of the guest then provide faclity to interrogate that property of quote / report in a common way versus the ABI risk of conveying vendor specific binary data formats in the kernel ABI.
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. > > An ABI wants to care about the abstractions around what the hardware > mechanism enables. The TD quote is not even at the end of that chain of > what the ABI needs to offer. The guest wants to use the TD quote to access > / unlock other resources, just like the SEV report is used to > "...provide the VM with secrets, such as a disk decryption key, or other > keys required for operation". > > That's where the ABI line needs to be drawn. I.e. for the guest to be > able to request the distributions of keys to unlock resources by a > key-type and key-descriptor. Enable userspace to interrogate an > attestation object without blobs needing to traverse the kernel. If the > remote service needs more than just a blob and signature to validate the > state of the guest then provide faclity to interrogate that property of > quote / report in a common way versus the ABI risk of conveying vendor > specific binary data formats in the kernel ABI. A proposal for how this space moves forward: 1/ Stop accepting new arch specific ioctls in this space and revert the Intel TDREPORT ioctl if its only reason for existing is "quote" generation. 2/ Define a container format / envelope for platform-provided attestation evidence. The observation here is that although it is too late to unify the evidence formats across vendors, they appear to share the common form of a blob with an ECDSA signature. That reduces the minimum viable attestation service to something that can generically verify an evidence-blob signature. 3/ Define a key-description format that considers a superset of the platform needs. For example a 'privelege-level' concept can map to 'vmpl' on AMD, but be ignored for now for Intel. 4/ For in progress enabling concepts like runtime measurement registers, look to reuse / abstract that behind the Keys subsystem existing support for managing TPM PCRs. 5/ Deprecate the multiple arch specific attestation ioctl interfaces in favor of this unified conveyance method.
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.
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.
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: > > >> > > >> 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. 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.
On Tue, Jun 27 2023 at 00:50, Chong Cai wrote: > On Sun, Jun 25, 2023 at 9:32 PM Dan Williams <dan.j.williams@intel.com> wrote: >> 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. No way. This is exactly how the kernel ends up with an unmaintainable mess simply because this creates an user space ABI which is not revertable ever. It's bad enough that nobody paid attention when the AMD muck was merged, but that does not make an argument or any form of justification to add more of this. Dan's proposal makes a lot of sense and allows to implement this in a mostly vendor agnostic way. While the AMD interface is not going away due to that, I'm 100% confident (pun intended) that such an unified interface is going to be utilized and supported by AMD (or any other vendor) sooner than later simply because the user space people who have to implement vendor agnostic orchestration tools will go for it as it makes their life easier too. The time wasted to argue about this TDX ioctl mess could have been spent to actually migrate TDX over to this scheme. But sure it's way simpler to flog a dead horse instead of actually sitting down and getting useful work done. Thanks, tglx