Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp31852imi; Thu, 21 Jul 2022 15:18:05 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t34EpB3evWR2Po1C6teA7A8Who9qzFiUJ73gEnOQej3nIkSktyXqWJMMKCzl81hAdt4Gzo X-Received: by 2002:a05:6402:5192:b0:43a:c589:4507 with SMTP id q18-20020a056402519200b0043ac5894507mr500993edd.177.1658441885411; Thu, 21 Jul 2022 15:18:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658441885; cv=none; d=google.com; s=arc-20160816; b=JvrpsYCQSHiUbgYWhmNjEblsCCRlElUkaB2yfQQjlhnnwb4Kkn6k95X68J/Xfa7GYW Bc5vfhpA7g2q5bq7HJLZE+u9pCXXDVctAnh6uW9LGxrfIVlMuLxPDMS7YvgpH40ngCCE UwGh2sZWitl6DEtoLwXg2uWq2nVEZ4bhIe/Z42D8Gl9AVUPsj3ViqdyyGVIyhoaGPkq+ Nk73wD0U2udxQZ/wFEicPSr93tl4ECl78SGGJZOzqSSiZceEd3TxsrYfilAw8426N93m LdHuJaXpJrvdbSb6jC7bH+kIV8v8RLXZsJJA1QJ1fX0hABbsnya2sbzy/7s6pKiezxq/ fzbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=rksd1bErmamSzO4cmf+rJBlBJejWq2NVqL44W/gGoPM=; b=B0n6+iVMJxA8AUbbGA6ZwMLi+7vvwS9kvnVU071vW/iY12I3B3kLpIojRtefj5bqyR ar8eFL96GOfNqq+YdDDLx5TWZX+2eIVT8MK5+b63+Bl28PAGu0QGmWY/wjh/pUcimd9b M4shxylfc2+QJ10gMgWGLhcx8OaegRvSnI+KUPD1jFibx4Bw4mM3QC69vAmxwkld+/Ag JmFVMKv/0sjs07/1UlnATJ/WRQNrcS3dHX00N+JKAF8XhQEJdhEPv9Ew8TRrPJ0RvJi5 xIeIqOqwI0d00AVBeq+hyYZzItVZaGtL1Ge9FaGiOjsEADpt54CkkeqiCuYwluJcQN86 YOyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="VKat/S16"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qk39-20020a1709077fa700b0072f67932939si4130809ejc.865.2022.07.21.15.17.40; Thu, 21 Jul 2022 15:18:05 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="VKat/S16"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232488AbiGUWIv (ORCPT + 99 others); Thu, 21 Jul 2022 18:08:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbiGUWIu (ORCPT ); Thu, 21 Jul 2022 18:08:50 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFB5B93C2B for ; Thu, 21 Jul 2022 15:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658441329; x=1689977329; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=A15/vVZpnpZfHrd9m7ClSkmBk0SMp9sEl8Bf2e15Ymw=; b=VKat/S161BbfhWvjsH2xtVU1gl8EVaRb621tba/HzJg2+HU3GMt5SrcF ekkHpnrSd6JYyPA4Wk2cSPPePSCK1gzfK1UFjloLULnOCoJUULu85O72j tB/gTbWKuNm52Cm5vDZ6YVjB9H31Kt/G9X5KrYP7cWZusHyk8aEb3VovP mM+0yZqLVkltH9QqxKVf9Zc6imtNa9WEghZB6OevUTC252LgC0qu4Ke9R uM5ZxyBwgiSS6aFyZtSv4AGf6KRlN5D+VwoE5V9+oNzYPX7snnkVVnbT+ PTNgHAQMYY/Zro76SYIwFP5/ttvwl5+TPPcsACUQWJtFkipfQcswdz7QT Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10415"; a="270217629" X-IronPort-AV: E=Sophos;i="5.93,184,1654585200"; d="scan'208";a="270217629" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2022 15:08:49 -0700 X-IronPort-AV: E=Sophos;i="5.93,184,1654585200"; d="scan'208";a="598633154" 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 15:08:48 -0700 Message-ID: <0b4af60c-73fc-054e-8a2c-7bf4544e77f6@linux.intel.com> Date: Thu, 21 Jul 2022 15:08:48 -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 , Isaku Yamahata Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Andi Kleen , Kai Huang , Wander Lairson Costa , 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> <20220721184221.GA3288872@ls.amr.corp.intel.com> <1fdecc17-8f4f-fceb-8da0-4a21ca0d58be@intel.com> <71f3326d-319b-c78a-345b-499001e766ff@intel.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: <71f3326d-319b-c78a-345b-499001e766ff@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_NONE 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: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dave, On 7/21/22 12:23 PM, Dave Hansen wrote: > On 7/21/22 11:57, Sathyanarayanan Kuppuswamy wrote: >>> How does the VMM know how much to read/write? I have a theory: the spec >>> says that R12 is: >>> >>> "Shared 4KB GPA as input – the memory contains a >>> TDREPORT_STRUCT." >>> >>> That's *A* 4KB GPA. The maximum is one 4KB page. That's the only thing >>> that makes sense because there's no length in the ABI anywhere. >>> >>> What am I missing? >> I think you are looking into the old spec. Please check the version >> "FEBRUARY 2022" >> >> Following are the ABI details: >> >> R11 - TDG.VP.VMCALL< GetQuote > sub-function per Table 2-3 >> R12 - Shared GPA as input – the memory contains a TDREPORT_STRUCT. The >> same buffer is used as output – the memory contains a TD Quote. >> R13 - Size of shared GPA. The size must be 4KB-aligned. > > Yeah, silly me. I assumed the ABI was stable and wouldn't be, you know, > adding and removing parameters. > > I still don't know how this all works. You just said: At a high level, the quote generation communication flow is as below: Entities involved are, Guest TD user app (send TDREPORT) <-> Quoting Enclave (QE) (Sign TDREPORT and send Quote) Steps involved are, 1. Attestation agent (in TD userspace)  will get the TDREPORT data from    the TDX module. 2. To generate a remotely verifiable Quote, send the TDREPORT data to the    Quoting enclave (QE). QE will verify the integrity of TDREPORT and sign    it with the attestation key.    * QE can be hosted as simple app in the host, or it can be hosted in a special      TD guest. 3. Method of sending TDREPORT to QE depends on the QE requirements. In most    cases, it will support TCP/IP or vsock communication models. So the attestation    agent can easily send the TDREPORT via TCP/IP and get the Quote data. But for platforms that do not want to support TCP/IP or socket communication, TDX ABI defines a method of getting Quote using TDVMCALL. It is a less common case. Our current discussion is related to this approach. Entities involved in this approach are, TD Guest user app <-> TD Guest kernel <-> VMM  <-> QE Communication flow looks like below: 1. Attestation agent (in TD userspace)  will get the TDREPORT data from    the TDX module. 2. Check with QE about the required quote size (it can be some form of    agreement between QE and attestation agent). 3. Allocate space for Quote buffer and update the header details like mentioned below and send the quote buffer and length details via IOCTL +/* + * Format of Quote data header. More details can be found in TDX + * Guest-Host Communication Interface (GHCI) for Intel TDX 1.0, + * section titled "TDG.VP.VMCALL" + */ +struct tdx_quote_hdr { +       /* Quote version, filled by TD */ +       __u64 version; +       /* Status code of Quote request, filled by VMM */ +       __u64 status; +       /* Length of TDREPORT, filled by TD */ +       __u32 in_len; +       /* Length of Quote, filled by VMM */ +       __u32 out_len; +       /* Actual Quote data or TDREPORT on input */ +       __u64 data[0]; +}; + +/* struct tdx_quote_req: Request to generate TD Quote using TDREPORT + * + * @buf         : Pass user data that includes TDREPORT as input. Upon + *                successful completion of IOCTL, output is copied + *                back to the same buffer. + * @len         : Length of the Quote buffer. + */ +struct tdx_quote_req { +       __u64 buf; +       __u64 len; +} 4. Once an IOCTL request is received, the kernel will allocate a Quote buffer of the requested size, and use GetQuote hypercall to send this request to VMM.    GetQuote (TDVMCALL type, kernel buffer physical addr, length of the buffer).     5. Upon hypercall request, VMM will further send the details to the QE. Once QE processes this request and generates the Quote, it will update the status details in the Quote header and copy the Quote back to the guest GPA. After completing the request, it will also send the IRQ notification to the TD Guest kernel. Event notification IRQ requirement is due to this step.     6. Once TD Guest kernel receives event notification, it will copy the    contents of the Quote back to the user buffer and complete the IOCTL request. > >> Current ABI allows attestation service and agent to decide the quote size. So >> we can't make assumptions on what that size will be. > > But, the guest *HAS* to make assumptions, right? It's allocating the > buffer and handing a pointer and size over to the host. It's also guest > *userspace*. In fact, this implementation *ABSOLUTELY* makes > assumptions about the buffer size. > > If host userspace some day decides it needs 5MB of space, then all the > guests will just stop working. This implementation is limited by the > max page allocator size. Agree. We are assuming that the user agent will not request buffer that exceeds the limit of the page allocator. But as Isaku mentioned, it is expected that the Quote size will only be in KBs. I think the main reason for ABI not limiting the size is, for flexibility and to support future requirements. Also, as mentioned above, this approach is not a common case. TCP/IP or vsock models are generally supported and can be used for Quote generation. -- Sathyanarayanan Kuppuswamy Linux Kernel Developer