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 691D5C433F5 for ; Tue, 19 Apr 2022 02:29:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344790AbiDSCcH (ORCPT ); Mon, 18 Apr 2022 22:32:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244392AbiDSCcE (ORCPT ); Mon, 18 Apr 2022 22:32:04 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 846882E688; Mon, 18 Apr 2022 19:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650335363; x=1681871363; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=Y1jcWKfWahIx2WpR/x2hL9GOikQOTZYyBLB86DBI79I=; b=LLrOx5fseTNurCu+rcCIIzdlQB/38EZpVH5yEhTvJWf7jIOVQtAthoUj qhQiPqCF9YqTXhwo7npPU8N/hSCBZuzeqYtjdN2AIR0NeKVP8a9E/I6DB HpAU0ommURdEuxF+7lllPI+YHhZaOvacFBd0LU4+PeocoSZddUtWjxTFt 7F5ISs1zfaEMbOrIXjiBU/0nfrCgICk0xummA3MdCyyTzCcl0CouUnTJa gRZbRIrdpX226E8d+KVdVRjS9lX+gukEHbl+A9lwxcg05S6YnwK15ZPP9 DIl/dHsAEZMcvcxPK6pWitjlZDnNMpamKm/CzXcTM5AHBKX345IQqoM3w A==; X-IronPort-AV: E=McAfee;i="6400,9594,10321"; a="326556869" X-IronPort-AV: E=Sophos;i="5.90,271,1643702400"; d="scan'208";a="326556869" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2022 19:29:23 -0700 X-IronPort-AV: E=Sophos;i="5.90,271,1643702400"; d="scan'208";a="657465581" Received: from jaspuehl-mobl2.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.254.31.185]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2022 19:29:19 -0700 Message-ID: Subject: Re: [PATCH v3 1/4] x86/tdx: Add tdx_mcall_tdreport() API support From: Kai Huang To: Kuppuswamy Sathyanarayanan , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Hans de Goede , Mark Gross Cc: "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Andi Kleen , linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org Date: Tue, 19 Apr 2022 14:29:17 +1200 In-Reply-To: <20220415220109.282834-2-sathyanarayanan.kuppuswamy@linux.intel.com> References: <20220415220109.282834-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20220415220109.282834-2-sathyanarayanan.kuppuswamy@linux.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2022-04-15 at 15:01 -0700, Kuppuswamy Sathyanarayanan wrote: > In TDX guest, attestation is mainly used to verify the trustworthiness > of a TD to the 3rd party key servers.  > "key servers" is only a use case of using the attestation service. This sentence looks not accurate. > First step in attestation process > is to get the TDREPORT data and the generated data is further used in > subsequent steps of the attestation process. TDREPORT data contains > details like TDX module version information, measurement of the TD, > along with a TD-specified nonce > > Add a wrapper function (tdx_mcall_tdreport()) to get the TDREPORT from > the TDX Module. > > More details about the TDREPORT TDCALL can be found in TDX Guest-Host > Communication Interface (GHCI) for Intel TDX 1.5, section titled > "TDCALL [MR.REPORT]". Attestation is a must for TDX architecture, so The TDCALL[MR.REPORT] is available in TDX 1.0. I don't think we should use TDX 1.5 here. And this TDCALL is defined in the TDX module spec 1.0. You can find it in the public TDX module 1.0 spec (22.3.3. TDG.MR.REPORT Leaf): https://www.intel.com/content/dam/develop/external/us/en/documents/tdx-module-1.0-public-spec-v0.931.pdf > > Steps involved in attestation process can be found in TDX Guest-Host > Communication Interface (GHCI) for Intel TDX 1.5, section titled > "TD attestation" It's strange we need to use GHCI for TDX 1.5 to get some idea about the attestation process. Looking at the GHCI 1.0 spec, it seems it already has one section to talk about attestation process (5.4 TD attestation). > > This API will be mainly used by the attestation driver. Attestation > driver support will be added by upcoming patches. > > Reviewed-by: Tony Luck > Reviewed-by: Andi Kleen > Acked-by: Kirill A. Shutemov > Signed-off-by: Kuppuswamy Sathyanarayanan > --- > arch/x86/coco/tdx/tdx.c | 46 ++++++++++++++++++++++++++++++++++++++ > arch/x86/include/asm/tdx.h | 2 ++ > 2 files changed, 48 insertions(+) > > diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c > index 03deb4d6920d..3e409b618d3f 100644 > --- a/arch/x86/coco/tdx/tdx.c > +++ b/arch/x86/coco/tdx/tdx.c > @@ -11,10 +11,12 @@ > #include > #include > #include > +#include > > /* TDX module Call Leaf IDs */ > #define TDX_GET_INFO 1 > #define TDX_GET_VEINFO 3 > +#define TDX_GET_REPORT 4 > #define TDX_ACCEPT_PAGE 6 > > /* TDX hypercall Leaf IDs */ > @@ -34,6 +36,10 @@ > #define VE_GET_PORT_NUM(e) ((e) >> 16) > #define VE_IS_IO_STRING(e) ((e) & BIT(4)) > > +/* TDX Module call error codes */ > +#define TDCALL_RETURN_CODE_MASK 0xffffffff00000000 > +#define TDCALL_RETURN_CODE(a) ((a) & TDCALL_RETURN_CODE_MASK) > + > /* > * Wrapper for standard use of __tdx_hypercall with no output aside from > * return code. > @@ -98,6 +104,46 @@ static inline void tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9, > panic("TDCALL %lld failed (Buggy TDX module!)\n", fn); > } > > +/* > + * tdx_mcall_tdreport() - Generate TDREPORT_STRUCT using TDCALL. > + * > + * @data : Address of 1024B aligned data to store > + * TDREPORT_STRUCT. > + * @reportdata : Address of 64B aligned report data > + * > + * return 0 on success or failure error number. > + */ > +long tdx_mcall_tdreport(void *data, void *reportdata) > +{ > + u64 ret; > + > + /* > + * Check for a valid TDX guest to ensure this API is only > + * used by TDX guest platform. Also make sure "data" and > + * "reportdata" pointers are valid. > + */ > + if (!data || !reportdata || !cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) > + return -EINVAL; Do we need to manually check the alignment since it is mentioned in the comment of this function? > + > + /* > + * Pass the physical address of user generated reportdata > + * and the physical address of out pointer to store the > + * TDREPORT data to the TDX module to generate the > + * TD report. Generated data contains measurements/configuration > + * data of the TD guest. More info about ABI can be found in TDX > + * Guest-Host-Communication Interface (GHCI), sec titled > + * "TDG.MR.REPORT". If you agree with my above comments, then this comment should be updated too: TDG.MR.REPORT is defined in TDX module 1.0 spec. > + */ > + ret = __tdx_module_call(TDX_GET_REPORT, virt_to_phys(data), > + virt_to_phys(reportdata), 0, 0, NULL); > + > + if (ret) > + return TDCALL_RETURN_CODE(ret); > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(tdx_mcall_tdreport); > + > static u64 get_cc_mask(void) > { > struct tdx_module_output out; > diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h > index 020c81a7c729..a151f69dd6ef 100644 > --- a/arch/x86/include/asm/tdx.h > +++ b/arch/x86/include/asm/tdx.h > @@ -67,6 +67,8 @@ void tdx_safe_halt(void); > > bool tdx_early_handle_ve(struct pt_regs *regs); > > +long tdx_mcall_tdreport(void *data, void *reportdata); > + > #else > > static inline void tdx_early_init(void) { };