From patchwork Wed Oct 26 23:16:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Huang, Kai" X-Patchwork-Id: 13021368 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 A5622C38A2D for ; Wed, 26 Oct 2022 23:18:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 465778E0010; Wed, 26 Oct 2022 19:18:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 415668E0001; Wed, 26 Oct 2022 19:18:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DCBA8E0010; Wed, 26 Oct 2022 19:18:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1E5AF8E0001 for ; Wed, 26 Oct 2022 19:18:24 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EDE121605C1 for ; Wed, 26 Oct 2022 23:18:23 +0000 (UTC) X-FDA: 80064666486.26.B9699DB Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf28.hostedemail.com (Postfix) with ESMTP id 49A34C0006 for ; Wed, 26 Oct 2022 23:18:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666826303; x=1698362303; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=MPNELNYfmCBpeNJA9LZsp7KToRLiYMVpcYL0jENfSoA=; b=KuHL3St2bl1Lc32RkVWcSo8TGgIdulowaVzp6TKylXSIkiOQ3cRlaDW/ jb8tGlxzd4hhrC0P+BnIjaVsuWbnFuu42bM7OrFDY/eevs/07ZuuqEZ26 BNBd055pf0xUjaKHVk8yqulfdc6Bwih8NBXjlYqw7M3Q3LpBLnlXJsfch OKHxgBXSfebU8oc0ssfUff9k/gW5MyFvnNiKPVG3Cese1kTdr5HrkdONQ nsmrLGjJcXADEBhJAN8H/BQmjGBmXV2OQrSYFFuZt9sewNuUTyiBV22eA W4au8S4E65/T3+XNsDqOEwG2LXH74oAVW/agrtoZK2LOOYD+cOzY2BagY Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10512"; a="394400475" X-IronPort-AV: E=Sophos;i="5.95,215,1661842800"; d="scan'208";a="394400475" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Oct 2022 16:18:22 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10512"; a="737446567" X-IronPort-AV: E=Sophos;i="5.95,215,1661842800"; d="scan'208";a="737446567" Received: from fordon1x-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.212.24.177]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Oct 2022 16:18:19 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: linux-mm@kvack.org, seanjc@google.com, pbonzini@redhat.com, dave.hansen@intel.com, dan.j.williams@intel.com, rafael.j.wysocki@intel.com, kirill.shutemov@linux.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, kai.huang@intel.com Subject: [PATCH v6 20/21] x86/virt/tdx: Flush cache in kexec() when TDX is enabled Date: Thu, 27 Oct 2022 12:16:19 +1300 Message-Id: X-Mailer: git-send-email 2.37.3 In-Reply-To: References: MIME-Version: 1.0 ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=KuHL3St2; spf=pass (imf28.hostedemail.com: domain of kai.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=kai.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666826303; a=rsa-sha256; cv=none; b=1xAhSFKqt8+av4LX19ob/Y+47A0LfjxvrdTkyJ/c9FiVb1zO7mvz7HaFafxgrIF+3SJpxg guU/DnmZFYzEwHBojUuINIMBkGu7T6AmO5x5Ts22yawlAeLYAAKoa1GOwmj+/LAmZgh/dN SmLQT4lGE0SvoRp0atTLIFbPyT3Kaxw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666826303; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ePTCdawNvu3rfYOxumBKIhD1n4rRJ+0wXTQhmCVBFbY=; b=CHsOsl/cZ7Lq6yKes3HC/RkMSGc8q3pU+MIgGrXlgwNSZ9df8+Mt1M+Kj4OU18fd1jn3QS i15ngvdvfBDtE7cKz8sR0QRV9E+B8xBMTMGU4Ds1Y5zGUHFm7kL84qAzlsMzpVOOm3yy9d PclyWMM9/sfMHE26PVMHG86MqGlA7JU= X-Rspamd-Queue-Id: 49A34C0006 Authentication-Results: imf28.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=KuHL3St2; spf=pass (imf28.hostedemail.com: domain of kai.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=kai.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam02 X-Rspam-User: X-Stat-Signature: c8tnhjnadyiggo3jrgkkgd1nghst3u3m X-HE-Tag: 1666826303-413401 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: To support kexec(), if the TDX module is initialized, the kernel needs to flush all dirty cachelines associated with any TDX private KeyID, otherwise they may silently corrupt the new kernel. Following SME support, use wbinvd() to flush cache in stop_this_cpu(). Theoretically, cache flush is only needed when the TDX module has been initialized. However initializing the TDX module is done on demand at runtime, and it takes a mutex to read the module status. Just check whether TDX is enabled by BIOS instead to flush cache. The current TDX module architecture doesn't play nicely with kexec(). The TDX module can only be initialized once during its lifetime, and there is no SEAMCALL to reset the module to give a new clean slate to the new kernel. Therefore, ideally, if the module is ever initialized, it's better to shut down the module. The new kernel won't be able to use TDX anyway (as it needs to go through the TDX module initialization process which will fail immediately at the first step). However, there's no guarantee CPU is in VMX operation during kexec(). This means it's impractical to shut down the module. Just do nothing but leave the module open. Reviewed-by: Isaku Yamahata Signed-off-by: Kai Huang --- arch/x86/kernel/process.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index c21b7347a26d..a8f482c6e600 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -765,8 +765,15 @@ void __noreturn stop_this_cpu(void *dummy) * * Test the CPUID bit directly because the machine might've cleared * X86_FEATURE_SME due to cmdline options. + * + * Similar to SME, if the TDX module is ever initialized, the + * cachelines associated with any TDX private KeyID must be + * flushed before transiting to the new kernel. The TDX module + * is initialized on demand, and it takes the mutex to read it's + * status. Just check whether TDX is enabled by BIOS instead to + * flush cache. */ - if (cpuid_eax(0x8000001f) & BIT(0)) + if (cpuid_eax(0x8000001f) & BIT(0) || platform_tdx_enabled()) native_wbinvd(); for (;;) { /*