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;
Date:   Sun, 25 Jun 2023 13:21:17 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Dan Williams <dan.j.williams@intel.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        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>,
        <gregkh@linuxfoundation.org>, <dhowells@redhat.com>
Subject: RE: [PATCH v3 0/3] TDX Guest Quote generation support
Message-ID: <6498a1bdc1db9_1dff294b2@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References: <cover.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com>
 <64966b842becf_142af8294a5@dwillia2-xfh.jf.intel.com.notmuch>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <64966b842becf_142af8294a5@dwillia2-xfh.jf.intel.com.notmuch>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?qXTJmaJuxqO4kBhE9SNxXcS3x2ImOhJ/TrYq/0U+WUSTgSH+30/0QLoleqQu?=
 =?us-ascii?Q?8omBajZ/Ok5dqdgP1sIzOUEFDVn9PoyviKz5Abogfs3hEhAzKFF8CLw8MFCR?=
 =?us-ascii?Q?s5zs/fuBMVptbqkNhRdLLWp2xJCzpHFZz5WNm0cq3Wa5b3P9f/4cQesaMMku?=
 =?us-ascii?Q?L/VbrhCdOy7rDtPd2rqDAWpgjbyQRmbp4K386pbqdqa3LsiDOsdUrLVhwXCl?=
 =?us-ascii?Q?jGQIsHxr/kWeaS81OmhxCfbCVA0EKEiXNNxaKVPYdb95KiYe00zFPeEOISLs?=
 =?us-ascii?Q?fxsBqU8BEVMBd3SViT23QeVbWLF8jw0VDXscd0STMw9uQzIxsNjwTMGXh7bu?=
 =?us-ascii?Q?4l0W3IYozsjg+dKT/3UQRomZrdNFtyCOVPWyt964Tiu3M1UBi6bbWxYelWbz?=
 =?us-ascii?Q?uFP2Z8BjbRSU5u97riO27blGSDCo2FGkff1ZX+9f2b4SXj+7Oo5GIMQ96zLq?=
 =?us-ascii?Q?6GArfIhXYK0Rgv/ks0UHztIZJ8StK7ulX0yl0xJy6mo0UQkGWI8riV+zdycH?=
 =?us-ascii?Q?+w7ffjC9XpGr0SrvrG5AFMCxMHVrBISV4DYZ53drjsDjUHscUfcBfrGq4qho?=
 =?us-ascii?Q?K32aj+uV2nShcYJo2ADdVe1SWMLb7B3iZhQNnsPjOivCKIZzpN9cNAjd7Kde?=
 =?us-ascii?Q?lfwkIkyWF3gjrRydlBwIxP8qsww62dLQVCye+hhbiLhs2WkMZh4Z7v+Esznb?=
 =?us-ascii?Q?q1RyrNbB6TN+3Ogf1R8wS6y0FtkUyVyE8tYMs9jgYhLD8B3bvV1WSRTjDkYb?=
 =?us-ascii?Q?Xd1Jbc63tmuYq5b+rmL3zLdOueKA8pb05jCjbGXNTnvLhqa6H8JJfn+1iQio?=
 =?us-ascii?Q?r5xRn0ib6beNqTpMo5Thnb5VElwMBZzTle31KeOJSyssWQySqNZuay2zzRnF?=
 =?us-ascii?Q?Z8LgJmdJmw4rnfnwnfygxKWEgFkDduXqooPTa4QaathR1mof0/NXURzxl9zV?=
 =?us-ascii?Q?3IYHls40rHma6SrfNjuwpOvDXlRoHU99u0OeIHtNddb0/YHqjTlKfQB4Mmou?=
 =?us-ascii?Q?hil8Qh13P6jRdZDZmhVDyEYUTB+KfBiRY54g2bPCe6Jq680TZOKhTI1QuiJX?=
 =?us-ascii?Q?ALP4NyN+6SSA1ZGDYqriHiAOHWFS1KjwVpVXJu3oykR5DZAvt0XiRMDljGIu?=
 =?us-ascii?Q?eo9KZv+hkKBJwMtQfgQRXjqRxaHBoi4v458YGWMC++Yx8hrZApRbNUkGlu7p?=
 =?us-ascii?Q?LK6X+d64qi2/s1Sd9LgST+VLSzMczKNZ4Q3IbAot1TJGjahNJOTv1/4WVkbY?=
 =?us-ascii?Q?AByZyBSXerXCDEwoqVFuJqV9Cp65Yax/Hne+g67ojkPfeLmgB6EQBPyowEHA?=
 =?us-ascii?Q?w7SLCflKBEz/6AhtY3/iSLfNg17UlkkGJ/8rIF2ZR1h5CfY8poDY+SMWy8QX?=
 =?us-ascii?Q?6SHgRcc6TP9mYbsDVKmlfzM8SbpawvFGTk1t+0VH5JerWpms6Z6wlNhROCr+?=
 =?us-ascii?Q?JoUtCPLjwlYJyx88b5Jbqn/eVJT3pB/WCr8o1Zzul/nswvIlcjJIrZxUk+i5?=
 =?us-ascii?Q?dXzaANijF0Ls80GnATvBTeVv8Xqu4mAKZt+PIiLZmxFEfFVd/djCGoJocPWZ?=
 =?us-ascii?Q?SMTc4TAVV5vk+H6HRCp+Xt+piW5lcxnvrUHHD5zZPg0iJ/pQ0EhTg0cArfB5?=
 =?us-ascii?Q?fg=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ef015b8-5abc-4c31-8d28-08db75b9bdbc
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2023 20:21:21.8184
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: fBt3al9eUKyG1pNVv3Tj846HtjS+/Cx5V/PDkVXd/TCJHvZfwB4/sXXL9l4kbxkiFNHNLEvdUZEz4+YkfvhyMUv3P1fO9+8bVIMDJvCPdbc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6143
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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

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.