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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E84ACC4321E for ; Wed, 30 Nov 2022 17:38:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 615296B0073; Wed, 30 Nov 2022 12:38:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59E036B0074; Wed, 30 Nov 2022 12:38:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43F9B6B0075; Wed, 30 Nov 2022 12:38:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3315E6B0073 for ; Wed, 30 Nov 2022 12:38:06 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 00C08810BA for ; Wed, 30 Nov 2022 17:38:05 +0000 (UTC) X-FDA: 80190816972.08.9C982A6 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf07.hostedemail.com (Postfix) with ESMTP id AEAC840014 for ; Wed, 30 Nov 2022 17:38:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669829884; x=1701365884; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=jgk+/gRksD/zcs3SEL3Csm7ScRic4ED0irw6NfZJsSk=; b=cEx6KGoqssczEWJctKvEeJQbzbJbv1FfozMbwPiCoN8lDnGFUW6iM/ap 5mwsxN1ZW/UBjw0ARynDGs6J5U+6r0j1LXRG5SjP5VA+EQJIytnVFjTtC BE3gMVpD/p60FxD+IAlZM+thaLYC3wF1nFkNU3nu1TgBrZEyJOjjb6lWF kHvPN7nTQ23F8CXfw0/gq8pSxCpie0iYU2kkhjr4q6HPkH7LhAt8oGOur RBD0K4Negap6gyhgOT8Tngjo/j6FnVT0BeElvkqM1LVbo4Lgiu7uEZeTl m5/xZrb/s5ESS22jO6EoDadsvKZGzhoHPkud5IvoOumZ+pbccOBAhdk9h w==; X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="298832521" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="298832521" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2022 09:38:02 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10547"; a="676903764" X-IronPort-AV: E=Sophos;i="5.96,207,1665471600"; d="scan'208";a="676903764" Received: from xwang-mobl1.amr.corp.intel.com (HELO [10.212.177.221]) ([10.212.177.221]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2022 09:38:01 -0800 Message-ID: Date: Wed, 30 Nov 2022 09:37:59 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v7 17/20] x86/virt/tdx: Configure global KeyID on all packages Content-Language: en-US To: Kai Huang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: linux-mm@kvack.org, seanjc@google.com, pbonzini@redhat.com, dan.j.williams@intel.com, rafael.j.wysocki@intel.com, kirill.shutemov@linux.intel.com, ying.huang@intel.com, reinette.chatre@intel.com, len.brown@intel.com, tony.luck@intel.com, peterz@infradead.org, ak@linux.intel.com, isaku.yamahata@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com References: <8d8285cc5efa6302cf42a3fe2c9153d1a9dbcdac.1668988357.git.kai.huang@intel.com> From: Dave Hansen In-Reply-To: <8d8285cc5efa6302cf42a3fe2c9153d1a9dbcdac.1668988357.git.kai.huang@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669829885; a=rsa-sha256; cv=none; b=QZ3WVfK7IPg7X+0llVcW53W0ViWR2cUgoGU364snnRXXINvyZ5jFk3vOmxwAYMGeyKRPNb ieLZuQ4aCj9NL4ommz/s637uakUdXnsk5fwYmpQLnAHdswxMZtxqGYr9T+qxJyvpbtRmd0 5j6BDzx9WIkX/bjPv2YYjdqjf2G1Sq0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=cEx6KGoq; spf=pass (imf07.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669829885; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lW30m5SbuJRS4kfGi8GvAIEbQeN3XvNUROQgFBgGMj4=; b=A22yQbKkTkHNi/zRwERCwsiiM9c4nG2LRek+2GKQpbKsO1WZ3awYKej803MRJlWgSxUPuf gaQnU6Ty171DafEa080PUn0PrKUVoYwEtZNfUkz/d5Z9XKJbdtsf9Rgc2AnMJqm1Si+FYm 4fMhRj2LZCW39oBXhEyo5bEv3PE3130= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AEAC840014 X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=cEx6KGoq; spf=pass (imf07.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Stat-Signature: 7wicrc86gobb5exbedx4a3howaut86ez X-HE-Tag: 1669829884-176790 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11/20/22 16:26, Kai Huang wrote: > After the array of TDMRs and the global KeyID are configured to the TDX > module, use TDH.SYS.KEY.CONFIG to configure the key of the global KeyID > on all packages. I want to circle back to this because it potentially has the same class of issue that TDH.SYS.LP.INIT had. So, here's some more background followed by the key question: is TDH.SYS.KEY.CONFIG too strict? Should we explore relaxing it? Here's the very long-winded way of asking the same thing: This key is used to protect TDX module memory which is too large to fit into the limited range-register-protected (SMRR) areas that most of the module uses. Right now, that metadata includes the Physical Address Metadata Tables (PAMT) and "TD Root" (TDR) pages. Using this "global KeyID" provides stronger isolation and integrity protection for these structures than is provided by KeyID-0. The "global KeyID" only strictly needs to be programmed into a memory controllers if a PAMT or TDR page is allocated in memory attached to that controller. However, the TDX module currently requires that TDH.SYS.KEY.CONFIG be executed on one processor in each package. This is true even if there is no TDX Memory Region (TDMR) attached to that package. This was likely done for simplicity in the TDX module. It currently has no NUMA awareness (or even trusted NUMA metadata) and no ability to correlate processor packages with the memory attached to their memory controllers. The TDH.SYS.KEY.CONFIG design is actually pretty similar to Kirill's MKTME implementation[1]. Basically blast the KeyID configuration out to one processor in each package, regardless of whether the KeyID will ever get used on that package. While this requirement from the TDX module is _slightly_ too strict, I'm not quite as worried about it as I was about the *super* strict TDH.SYS.LP.INIT requirements. It's a lot harder and more rare to have an entire package of CPUs unavailable versus a single logical CPU. There is, for instance, no side-channel mitigation that disables an entire package worth of CPUs. I'm not even sure if we allow an entire package worth of NOHZ_FULL-indisposed processors. I'm happy to go run the same drill for TDH.SYS.KEY.CONFIG that we did for TDH.SYS.LP.INIT. Basically, can we relax the too-strict restrictions? But, I'm not sure anyone will ever reap a practical benefit from it. I'm tempted to just leave it as-is. Does anyone feel differently? 1. https://lore.kernel.org/lkml/20190508144422.13171-1-kirill.shutemov@linux.intel.com/T/#m936f260a345284687f8e929675f68f3d514725f5