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 21:31:39 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Sathyanarayanan Kuppuswamy 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Dan Williams <dan.j.williams@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>,
        "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: Re: [PATCH v3 0/3] TDX Guest Quote generation support
Message-ID: <649914ab3de4d_8e17829490@dwillia2-xfh.jf.intel.com.notmuch>
References: <cover.1684048511.git.sathyanarayanan.kuppuswamy@linux.intel.com>
 <64966b842becf_142af8294a5@dwillia2-xfh.jf.intel.com.notmuch>
 <cdd04046-4bcb-d6fd-1688-0a85546e7b91@linux.intel.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <cdd04046-4bcb-d6fd-1688-0a85546e7b91@linux.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?OvFTD2WE/XBQss2vroFS5n1tOxcYhsVtI9XUeQjL/D6Ion8n2iIdhqpEj/?=
 =?iso-8859-1?Q?FFTpZ5Gc/YfywSP6Wu+jbzC3k+i363KlJnxOMz7Eq0theEV1MNjRZH3Rpd?=
 =?iso-8859-1?Q?7Yc+IYZ+kWLckSBPKhQevT4Y7SvbZ323S7D9Vbgpzn2INb3mlJowsD5cYp?=
 =?iso-8859-1?Q?6/mApe42CVlvfM/bQKqUrDfbh4da9lwxgJLddfhjetDD+YtT1o6UE0K+Hr?=
 =?iso-8859-1?Q?i5BGvJIdUxBiUt8TlvYDE2+TrR6xsX0bIA/Obx2Cjm239nFaUMZPWrCDdB?=
 =?iso-8859-1?Q?TpRYRwHfCziANeTfkJ6FmWq+a8cF23kRxuwO7PXRN/+YV9mVcg/r3/ol+T?=
 =?iso-8859-1?Q?yuNMDt4okDJQOYIy/6DxUypBrtIzBDE+72iTpN3Sw2LGv17wnPCJ6pd94D?=
 =?iso-8859-1?Q?VVJn3rAQ/sv/GWVJ7EZkWKaTjQ8RcyOfWLi5YxLwvngqfQCl0LSPFrZqt1?=
 =?iso-8859-1?Q?gVvIXfB09wQHjW2+2mqUzjWd4JyXAvFdZesb0al2n5vcKSJuyzTFimZyTf?=
 =?iso-8859-1?Q?wHWBuOtymUWiVj6e5ZxU+uusq4EfLGu4CqfqNBWY+VWeDBxY7QQw6h+5hi?=
 =?iso-8859-1?Q?S2kZG9SECA+VLofn7/CHx9E9enpgcK+orIf4Yf3Lc+NPAB4z3W3jJhuLBX?=
 =?iso-8859-1?Q?vUfTejbcb02/VIWfkdS1ydY6HsOP6sOHa4pgb8f0qgjuJ8wq4JXnddL30A?=
 =?iso-8859-1?Q?bxLycOsNBQ+6yd1asuKek3T4ye+/ON+oBurI+pOker6dWsz1MrbDupisBf?=
 =?iso-8859-1?Q?/rLJkwGKP4pAQEnz4SDLoRvhBnqIPBBBq50XmT7wBPrLy5q3SODUw2dC1k?=
 =?iso-8859-1?Q?QKmDSwEp/uIPlJIBediNql2JnEEHxOk2bCzxm/6Knk01DCrpJnuMmRFqrb?=
 =?iso-8859-1?Q?r8ik1as3smn34p9MKYq+Qua18qcg6gsoXzjO+wvA196XPkxaXup6gi3j1F?=
 =?iso-8859-1?Q?j7yFWYmLGWh291F4c2APSNOC62iNN5efT3Ru7T8DJfqWYutGCI/cM+22my?=
 =?iso-8859-1?Q?swDlRyfgM5Uo0j48BK8tj+MT5P1ZJwcRvDcP6k5dZf/6vWr/4gYi/2en6M?=
 =?iso-8859-1?Q?c45WuASrOBnheFw/3ITyBKrPso8fEJuUpdFQk9/Iw9YlMWcs2kZv5GH+VF?=
 =?iso-8859-1?Q?2LbYXGWJqvXb7dQG7ogtSJf6Uz5TElVbGU15xWzbsGbiNMi6uQpPo24qkX?=
 =?iso-8859-1?Q?cEtOLK9eEv/O4KTwUQ6aOmLWG8eJ+VpVfSAzgyv4MEzSeAv/XvViND4arO?=
 =?iso-8859-1?Q?/wEPp4tx/2i5bTZN4cRRw0C4/75hYRnrJvLo/uVvQ921btpJeWhvyAnm1o?=
 =?iso-8859-1?Q?TkqvymoGfXWM4+65ud/Boh7FzQpg5cZ3HTTq6bQXfbNbR9K8lXyBv7wSJg?=
 =?iso-8859-1?Q?BB12u51IiiVTHchq6WlrdvZF8XFZnx/ni6e6EjRQy5L1N72+QiDEn6l38r?=
 =?iso-8859-1?Q?VQCDgZ/7f7rxsE8qp+3UhrBDCbXwbbrZZ766P76kdyLoJ+gWF2GotNOJvU?=
 =?iso-8859-1?Q?F1yFAruP+mpMhsqCusj8E8F2upwrwaooQOxpejcCnsCJ/vgIZa94Nu3BRr?=
 =?iso-8859-1?Q?71p3clrWQGZH8aUxB9SknuMOVU3PPHSXftpz8YRDER092hTS4qLl3+LvxX?=
 =?iso-8859-1?Q?AY4piGi6X7okzNL+8q42xfo3lzACZhQoM1yFbKZxFZJ+ISXRPLSj7Svg?=
 =?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ffb3a67-32e3-4c1c-aabb-08db75fe3e8f
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jun 2023 04:31:43.6363
 (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: vXQlGg4d1M9sKx1sgY7xMI8n12yrANDXpLQA10aawEhvmHoqeIUUoU7NG2aNB7RY7Cm7n5nLgSG/qKM4FfJhGrNg2FeFyG6UO1WQZLNN27k=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB8061
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,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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

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.