From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39BE9EE49AE for ; Wed, 23 Aug 2023 07:33:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233363AbjHWHdN (ORCPT ); Wed, 23 Aug 2023 03:33:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233342AbjHWHdL (ORCPT ); Wed, 23 Aug 2023 03:33:11 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11525128; Wed, 23 Aug 2023 00:33:10 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1692775988; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/S8aAMC8431wDl9EHieHaDMQtPnYNA9A+BMaoDCWW+Y=; b=p3b//x87LF4MIS/ydL5RQPDyLPAa3wrJ8ZuI1YF5NmpSVzakWWcYXUcNiAmulCkgSMuHfl pBcVXeoFemeMmwv+M+gjYtmZIRggmYr8+3Uub9vjYchbDMXHVderVZWyLbdxL711mzcHoD qLvzmoOnjs3lBLquIAEbSJChuFqOMgF9Wde2tPcNAOJ/riVPcq/Fwg66kWVfH9xP854OuZ QOVRnX0HAXS5yQiti8MJ+LoFLGW3XKk1huGDQCjGVwy3QBUkxR4ygYoLPx9YTGXOonPwUk ivHnhdLU8R8QHpz5oMuk2wpw6QFY7JgqOuC3hvWenp5hKbgonNnwngLeadrJjQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1692775988; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/S8aAMC8431wDl9EHieHaDMQtPnYNA9A+BMaoDCWW+Y=; b=Sm4+LbiyXoHegImmukuqOtU0ct8r9zucugT0HQj8DWGSLsSpC2ALLcb8vFcgdmq4TAspsd iWBQPT58aDXQGXBQ== To: Chong Cai , Dan Williams Cc: Sathyanarayanan Kuppuswamy , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Shuah Khan , Jonathan Corbet , "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Wander Lairson Costa , Erdem Aktas , Dionna Amalie Glaze , Qinkun Bao , Guorui Yu , Du Fan , 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 In-Reply-To: References: <64966b842becf_142af8294a5@dwillia2-xfh.jf.intel.com.notmuch> <649914ab3de4d_8e17829490@dwillia2-xfh.jf.intel.com.notmuch> Date: Wed, 23 Aug 2023 09:33:07 +0200 Message-ID: <87pm3edxho.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27 2023 at 00:50, Chong Cai wrote: > On Sun, Jun 25, 2023 at 9:32=E2=80=AFPM Dan Williams 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