Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp1144319rwr; Thu, 27 Apr 2023 13:02:35 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4uutmJwh4lvjad/IFxpSuxRQsfuVeZsc/82BU6qSxJGQpeFJHmJE+P+78udRRkvBcXd4ao X-Received: by 2002:a05:6a20:2447:b0:ef:6883:cfc3 with SMTP id t7-20020a056a20244700b000ef6883cfc3mr3594981pzc.58.1682625755449; Thu, 27 Apr 2023 13:02:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682625755; cv=none; d=google.com; s=arc-20160816; b=cpkN2pS5IQ9+L2GmpYR3w+A/sN1Qjh2phxbonTGAfN+bODpFaiebJiEV1s8bOpl/Yr bvhuGaEMzeaIfKoRhTcsQn0r9dYpgI6qXNatZPzCVIwnoHj90tHIHn3BCGg0uKOrgCMs 5p5h98W6gqHLPp7AA37ByMHhr6lOF1u2xv4Akii8vBDLrTkBtnNCzuhNn6TUe9tY7pc7 eUaK9gwHSWfGy3XI9vPnojDBw5WvYNGSqK74HkWsB1Hj8lQSut5BEjp7rgAllcw+QH8O uWCRIzBMfSkpNGe5vMhRCiS1hkuR0mRiLvSd8jTZjCDBcWkQ5Z+OGKRVklSgRZ/c/g5D atYA== 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=qBqMSEJfIbydVV6yu5+y/UALeOhCPJCWLCTEXejQ1+w=; b=pff+xuQUj+SzkeZJqYAxWgz9SEhXjZUJkQEWDO2HKR0Xu1AHq4vOV5r4n043Ac3EeG AKS2NjdFOsrus+cAxCs8DmPtzxNGy7iBQw5WNoXOkj0OKKvB+Uw+EQj26wTmEBdPFXo1 dC67wY7Sy/v4gUgZ8eQF0I4Fsw5AxfD0Y0FgVzkpZFUsXrW2J/qXOd2KpBYkqSbozfwN NnpGriGPLcKkZv9lbfeTNrtF8FR8QZ0IKmpttPxBO3LKfZXFlnbwgT9fm6fWDTcumE7D 2dMe9G+f06BB4iEEBSE8Np9GDnGBxFwyfPARjpl3NvRQyKIbAUSrO6jZ0x34XMf5cppS yEKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Tt8qcUcY; 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 i9-20020a17090332c900b001a6b78ede3dsi20813807plr.581.2023.04.27.13.02.21; Thu, 27 Apr 2023 13:02:35 -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=Tt8qcUcY; 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 S1344017AbjD0T5C (ORCPT + 99 others); Thu, 27 Apr 2023 15:57:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229750AbjD0T5A (ORCPT ); Thu, 27 Apr 2023 15:57:00 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 391DF1FD0; Thu, 27 Apr 2023 12:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1682625420; x=1714161420; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=haUZlRZVpKJjs4ThNpRF4P6XcJnbRFVkaRfj4rKvGQM=; b=Tt8qcUcYkXFpLJ4j3rDUq1mJ++3CQ4IHBrXyhcIqKzLLFcmYePmf4fOu FXKqk5dDER9tk4WZjRi2x6ffIY7m/K2APq60GhSC/DFAOX6Wy7YNjW7Dl YaqF2fcP4YJJWE7PX3pUqfkxEv1sR3KvIj02g1ssg9svgekTbIGPAbuOV 6Q0PbiwJLSZ4B9YHs0WRmNCI4HyAGB3NB3QKrgeCOR7QLJU4fb6+mdwPS 8x5Xp/+Q/dtSPdK3SHUlaZ5364TqFfLQOWbcNGoYlyazEOiWe31woRvZh owrS23sNdh2qe949qrjLuwS42QNbJ+yKjdX5AJmq4DQj5MJsOI6txZVj4 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10693"; a="336556487" X-IronPort-AV: E=Sophos;i="5.99,232,1677571200"; d="scan'208";a="336556487" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2023 12:56:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10693"; a="868857114" X-IronPort-AV: E=Sophos;i="5.99,232,1677571200"; d="scan'208";a="868857114" Received: from jonnaman-mobl2.amr.corp.intel.com (HELO [10.212.24.30]) ([10.212.24.30]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2023 12:56:58 -0700 Message-ID: <7d3f1877-8762-34f4-f1bb-c5c2924c2b77@intel.com> Date: Thu, 27 Apr 2023 12:56:52 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v2 3/3] selftests/tdx: Test GetQuote TDX attestation feature Content-Language: en-US To: Sathyanarayanan Kuppuswamy , Dionna Amalie Glaze Cc: Thomas Gleixner , 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 , Chong Cai , Qinkun Bao , Guorui Yu , Du Fan , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org References: <20230413034108.1902712-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20230413034108.1902712-4-sathyanarayanan.kuppuswamy@linux.intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, 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: X-Mailing-List: linux-kernel@vger.kernel.org On 4/27/23 12:10, Sathyanarayanan Kuppuswamy wrote: >> Shouldn't req be zeroed before populating reportdata? We wouldn't want >> uninitialized memory to leave the guest. I know this is just a test, > There are only two members in struct tdx_report_req (reportdata and tdreport). > The reportdata has already been updated here, and the tdreport will be updated > by the kernel on output. Since TDX_CMD_GET_REPORT0 IOCTL handler uses an > intermediate kernel buffer to the TDREPORT and copies the generated report back > to this user buffer, this uninitialized tdreport data never leaves the guest. Is that really even relevant? I mean, we could implement the whole thing with get_user_pages() and then just pass the physical address of the reportdata and tdreport down to the TDX module. It doesn't matter either way. The data is going from guest userspace to the guest kernel to the TDX module, all of which are trusted. It's a selftest. I'd just leave it alone.