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 9F58AC433F5 for ; Wed, 20 Apr 2022 01:26:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345037AbiDTB3a (ORCPT ); Tue, 19 Apr 2022 21:29:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232010AbiDTB33 (ORCPT ); Tue, 19 Apr 2022 21:29:29 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 378AD23BC4; Tue, 19 Apr 2022 18:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650418005; x=1681954005; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=mbBwslPLaoBfylvW/dhJ1OLBSlP7qYZg3Cvd31qjORE=; b=CGW8trYZ7koQ47kn2LlAg7TkxqunsCuFhU7JYFAjDdaBz3in7He7YYGz GfOlp5+lHQFlk7N5slDxiYDdAxRp63TkJ3qY9FEpw4YlnMnzjCaZDCS7v JZK41CI20P4OcnG+l7T9NLi4Aj9nmjGmO34zstVUtvjgdhgCnxM85BdDq +nLSwP4XsnxvX66ICG+Qug2ELP6OMSThtW9I5szLe1dnx/GvRUESjIKCA LWwTwJyAtTMCqvxFYUcXYTpuG/oV1aFqS6ZrxPxm2ECY3NEnwGI2B2wU+ fAg4sn9OO2E1qpsXkqBx2Y10KqpM8lyNqnjqRejlxypsFR6umooMUV2RA A==; X-IronPort-AV: E=McAfee;i="6400,9594,10322"; a="244495224" X-IronPort-AV: E=Sophos;i="5.90,274,1643702400"; d="scan'208";a="244495224" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 18:26:44 -0700 X-IronPort-AV: E=Sophos;i="5.90,274,1643702400"; d="scan'208";a="561918375" Received: from ktuv-desk2.amr.corp.intel.com (HELO [10.212.227.192]) ([10.212.227.192]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 18:26:43 -0700 Message-ID: Date: Tue, 19 Apr 2022 18:26:43 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.7.0 Subject: Re: [PATCH v3 4/4] platform/x86: intel_tdx_attest: Add TDX Guest attestation interface driver Content-Language: en-US To: Isaku Yamahata Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Hans de Goede , Mark Gross , "H . Peter Anvin" , "Kirill A . Shutemov" , Tony Luck , Andi Kleen , linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org References: <20220415220109.282834-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20220415220109.282834-5-sathyanarayanan.kuppuswamy@linux.intel.com> <20220420012032.GA2224031@ls.amr.corp.intel.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: <20220420012032.GA2224031@ls.amr.corp.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/19/22 6:20 PM, Isaku Yamahata wrote: > If timeout occurs, the state of adev->tdquote_buf is unknown. It's not safe > to continue to using adev->tdquote_buf. VMM would continue to processing > getquote request with this buffer. What if TDX_CMD_GEN_QUOTE is issued again, > and tdquote_buf is re-used? This part is not clearly discussed in the specification. May be spec should define some reasonable timeout and teardown details. Regarding not using this buffer again, what happens if we de-allocate it on timeout and the host still updates it? -- Sathyanarayanan Kuppuswamy Linux Kernel Developer