Message ID | cover.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp6171139vqo; Sun, 14 May 2023 00:49:24 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4O7iT6jelfG7nmKIg0/n+Pe3a8Km3q7XEbfk35320NIL2UMyC1cACTWhBsDY8rwzsUSCet X-Received: by 2002:a17:902:eb46:b0:1a6:5487:3f97 with SMTP id i6-20020a170902eb4600b001a654873f97mr28602408pli.64.1684050564357; Sun, 14 May 2023 00:49:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684050564; cv=none; d=google.com; s=arc-20160816; b=cQKVKU7N+wQSikiUt9xOjsohOioXZx2X88VOJnR52PzFgnR1rNLLOxUZ4C5WLXJso4 YzCG64rv9Nxv//xeQWk698kj+ltW2dxKD4cgrYr8z2l4owBfuSHsT9UPBnTedy4cy8ym ak8cV6wact+JXIpLBGHd5GZI9YLf+uJhCiQ6/E6AOMfpbypJYN4q7+RGFfIaJ57cCTb7 qXRW1lpDcyCfwXtznXWRuVK2QIiu+hUXzwh9mz/Ggc90ix5aFID7Icou7D2n0LrLqrfN sapypRRBKviXPfS/6PtTma2VLQYlTWWun1afpBljCe1418uBiLi0iureuxT+owH1nskM crNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=lvpjo6CqRQfMoYq9xtaju+2Dl8jN4Llp5Xb1QrwCXrI=; b=bXiNzBXcBdEKoHvQhtVBa1eqLjmpFBkTqRsbtCy7/uWKy2hB+VtzpSH2ynQOfBCl/2 ojIKq/KPcTVImpismLbWNIM88OyxS9uYOc9fCR8Yazoo0V2EpBnEQw8BCyKPVTkbGaPR p05feIsm9RNLp9CKzy/E3AQ2tcToIslYcaAL1XzBHkWaFqKNHW2r76kGlFxRg2hHngLL /7123axv2FTOcCzMzugy2UK+aRYSJluG1yKx+JgYbFRkBZ5h/Hi1yqF5ukceSdrS/LFI 4X11Zc2xnFHaOUBeTWfJ5jYjdkjBmfFoRSdnfHHI5Ag7Kjvp3N1OU1Z2Cmm2PNmTxYe7 EnHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cxCsUnth; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z17-20020a1709028f9100b001a69fe5f560si12309919plo.444.2023.05.14.00.49.09; Sun, 14 May 2023 00:49:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cxCsUnth; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230043AbjENHYE (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Sun, 14 May 2023 03:24:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjENHYA (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 14 May 2023 03:24:00 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1C0F199E; Sun, 14 May 2023 00:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684049039; x=1715585039; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=npeBkINJGxSpUKevbIGygQlsBP2qc6pkrXvu4pgq/P0=; b=cxCsUnthsil2N/LWw/zopFTfo0uRrDGlaIxYMecg1zSHGRGENx96OmfR yaQ2b+yDwuuL7e3Pvft0IAECx0cLSver+2xoIYFtkduhq6OcKpVFG3yl9 M884sFg0y47xXX/mO3+AVAWgWZNnhldC9OBcqmyaeBSsa54WfiadVsdcI o9bGs4622B99q09T7nHNiviEb9W2gAHXPqVBuhW2RU2zwtueo/2InAtt2 Tg2HfrKkMXRaYW67nXOiBR4WgmvlXBmczbb13YLrFLfuYJeQ7Tz3PCqn1 2jbk9GTxeO0N+ai6ewnqub2WNdi1UHHhWuj8FygdVPNMmtiUvwXEHDBZm w==; X-IronPort-AV: E=McAfee;i="6600,9927,10709"; a="354167273" X-IronPort-AV: E=Sophos;i="5.99,273,1677571200"; d="scan'208";a="354167273" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2023 00:23:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10709"; a="731262936" X-IronPort-AV: E=Sophos;i="5.99,273,1677571200"; d="scan'208";a="731262936" Received: from mply-mobl1.amr.corp.intel.com (HELO skuppusw-desk1.amr.corp.intel.com) ([10.212.130.17]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2023 00:23:57 -0700 From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, Shuah Khan <shuah@kernel.org>, Jonathan Corbet <corbet@lwn.net> Cc: "H . Peter Anvin" <hpa@zytor.com>, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, Tony Luck <tony.luck@intel.com>, Wander Lairson Costa <wander@redhat.com>, Erdem Aktas <erdemaktas@google.com>, Dionna Amalie Glaze <dionnaglaze@google.com>, Chong Cai <chongc@google.com>, Qinkun Bao <qinkun@apache.org>, Guorui Yu <GuoRui.Yu@linux.alibaba.com>, Du Fan <fan.du@intel.com>, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org Subject: [PATCH v3 0/3] TDX Guest Quote generation support Date: Sun, 14 May 2023 00:23:43 -0700 Message-Id: <cover.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765855004756170536?= X-GMAIL-MSGID: =?utf-8?q?1765855004756170536?= |
Series |
TDX Guest Quote generation support
|
|
Message
Kuppuswamy Sathyanarayanan
May 14, 2023, 7:23 a.m. UTC
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(-)
Comments
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.