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 68919C43334 for ; Thu, 21 Jul 2022 17:25:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229681AbiGURZH (ORCPT ); Thu, 21 Jul 2022 13:25:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229461AbiGURZF (ORCPT ); Thu, 21 Jul 2022 13:25:05 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C378354642 for ; Thu, 21 Jul 2022 10:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658424303; x=1689960303; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=iFVJ2PD2NWlvU7WTBpY338s4u7DT0v69UFMKVGkspzM=; b=ajhbbdZvMexuapU/gKVtVdHnXu+fI0GjDfqMQAIXYkPjccw2ISsluy6d gNx7LvTgb4tdQuomimBnN7NnAdae2Qf0aITssA5J1+S5zggKTBstDzbZz kneOoieM5mHRvGutqk6MhOP5xS68KZd2mYBpy5H8DwpRtBaBvWP9wGeP5 Pke16Vef7+c/X1bITX4jPSIRvV0CsK01VOF+bZutHBymU8LwbjEAFQ1Ia KIbSoTicxLv40r5VbWjB1MytlRX5Wi+WCXPkWkUDMYbaL4J65bmiC72E9 sH7jHRt6HIl0K71DE8IecQ91SuuExUp1SL8i6MaPmKcrejE0xHuNJaFEn Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10415"; a="287872386" X-IronPort-AV: E=Sophos;i="5.93,183,1654585200"; d="scan'208";a="287872386" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2022 10:16:50 -0700 X-IronPort-AV: E=Sophos;i="5.93,183,1654585200"; d="scan'208";a="598542459" Received: from sattaran-mobl1.amr.corp.intel.com (HELO [10.212.246.186]) ([10.212.246.186]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2022 10:16:38 -0700 Message-ID: Date: Thu, 21 Jul 2022 10:16:37 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.11.0 Subject: Re: [PATCH v8 5/5] x86/tdx: Add Quote generation support Content-Language: en-US To: Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Andi Kleen , Kai Huang , Wander Lairson Costa , Isaku Yamahata , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, linux-kernel@vger.kernel.org References: <20220609025220.2615197-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20220609025220.2615197-6-sathyanarayanan.kuppuswamy@linux.intel.com> <214e24f0-5236-be8d-024a-da48737d854a@intel.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dave, On 7/21/22 10:02 AM, Dave Hansen wrote: > On 7/21/22 09:54, Sathyanarayanan Kuppuswamy wrote: >> >> On 7/21/22 9:49 AM, Dave Hansen wrote: >>> On 7/21/22 09:42, Sathyanarayanan Kuppuswamy wrote: >>>> On 7/21/22 9:08 AM, Dave Hansen wrote: >>>>> On 6/8/22 19:52, Kuppuswamy Sathyanarayanan wrote: >>>>>> For shared buffer allocation, alternatives like using the DMA API is >>>>>> also considered. Although it simpler to use, it is not preferred because >>>>>> dma_alloc_*() APIs require a valid bus device as argument, which would >>>>>> need converting the attestation driver into a platform device driver. >>>>>> This is unnecessary, and since the attestation driver does not do real >>>>>> DMA, there is no need to use real DMA APIs. >>>>> Let's actually try to walk through the requirements for the memory >>>>> allocation here. >>>>> >>>>> 1. The guest kernel needs to allocate some guest physical memory >>>>> for the attestation data buffer >>>> Physically contiguous memory. >>> Remind me how large the quote structures are. >> It depends on the attestation service. In addition to TDREPORT (1K size), >> during quote generation, additional data can be included in the signed >> quote. So the spec allows variable length. User agent will communicate with >> attestation service to identify the appropriate buffer length. Our test >> uses 8K buffers > > What is this "additional data"? Is that "REPORTDATA" from the TDX > module spec? > > "Additional REPORTDATA, a 64-byte value, is provided by the > guest TD to be included in the TDG.MR.REPORT." It is not the REPORTDATA. REPORTDATA is already included in the TDREPORT during REPORT generation process (using TDG.MR.REPORT). Spec does not clearly define the details about the additional data. I think it is related to certificates. Isaku, do you have more details about it? Current ABI allows attestation service and agent to decide the quote size. So we can't make assumptions on what that size will be. Following is copied from TDX Module specification, sec titled "Measurement and Attestation" An Intel SGX Quoting Enclave, written specifically to support quoting Intel TDX TDs, uses a new ENCLU instruction leaf, EVERIFYREPORT2, to help check the integrity of the TDG.MR.REPORT. If it passes, the Quoting Enclave can use a certified quote signing key to sign a quote containing the guest TD’s measurements and the additional data being quoted. > > -- Sathyanarayanan Kuppuswamy Linux Kernel Developer