From patchwork Mon Nov 21 00:26:41 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 23495 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1325654wrr; Sun, 20 Nov 2022 16:40:45 -0800 (PST) X-Google-Smtp-Source: AA0mqf73hMo1nT1c7txYs5FVMNqSsSbcwMf6FPH1Nb2T8VBYHGAyYSVj6KxpERlRiPUP5v5wDAdl X-Received: by 2002:a65:5b44:0:b0:477:1bf6:73b6 with SMTP id y4-20020a655b44000000b004771bf673b6mr7183670pgr.36.1668991245600; Sun, 20 Nov 2022 16:40:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668991245; cv=none; d=google.com; s=arc-20160816; b=BHmJhMbV27jBKc/LiCt140aXqLXwuj3FaHD/e23SJ0NH3gKrreWoI8+CWiTCm40xFn 8lo3OkhH9riuZgbrsjczqONmJzp37YdtwRhfTc6BcpYVu/3T+JzRzXeg3Fo/l/21Lj83 2yO3pfhTFeEAAvypxrSUPeijXSXb6ZGvGwyvWq0WE6GU5FlGBPSyX9o9J/XBZ5eQwRYe ctiUgLNuOjHddXIsiQUUE3fPbvGwufla2iIQyDXpwwl3T3/ZIFqtSUyfX570sjjeYG6N cBsYlxZmGsBZJ2cX1UxLaO2qqdwiPLQIQJF23LarIlr3ouAhUptxEcgAus7rpQPjzc1H yvwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=0HsaI+F+Q6SMDl5C9timeO1Ls7uwIsud4GJwh7yr45s=; b=BbfaIJG6Vdivq47Msu6FsMA6u7HWHVDljCL7PfQjZ5inEEvfvyEBLUk32Xmr4qm9LM LGtItmQl17XXRwTb2Tn34h9c/ZfBZ4jLQxWFMoj+R1A3ngRUQqv4t+P9O4L0mhJK6EdI LsDgRUBVnbyXlGk18vajHz317F5vaY6vLlSxrVULSt736t+cNqSEyQmAPGtCdyp3Guo6 9q7tsvAGiAIvExKFBvpsG6ohLy58lNB37McxzKKPt8Ko3bNoccU5nHFkBTO/C0Ot6NPR X0KmqwwCn/1ZODdBMVzKTPLSs2JradxG/FKj26bhInXQBbv37euEC0XPFJrQ0H9f3nrj BmRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=SzzD6Q46; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lw6-20020a17090b180600b0020d65f31df8si16318238pjb.143.2022.11.20.16.40.32; Sun, 20 Nov 2022 16:40:45 -0800 (PST) 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=SzzD6Q46; 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 S229964AbiKUAbH (ORCPT + 99 others); Sun, 20 Nov 2022 19:31:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230047AbiKUAa2 (ORCPT ); Sun, 20 Nov 2022 19:30:28 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6822E1E3F2; Sun, 20 Nov 2022 16:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1668990537; x=1700526537; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=B4X5vcXsxt6uAK36/XCY9Qp+zNxFIBT0eQmTkgHAVxg=; b=SzzD6Q46Q4FD3NF7YWB6fd0YbJTjY0CHQ3HvPkv2bH8XNUftTY5gaSMV MagRbX4pNvR3qNLUDpmE6n/0w0hbfwXyX0F8lNDkMZXwOT8f7p3Y9XKvE OMOHNSSpvjtquVaHHE2x48bxkq/9ODmqHVicFR92manNvDpe72B5aUEbQ Lo76wGTUdHo9d5Hj6hmtwW+RxagQKI8ZMX8qg9Dvx+1J7N0z+0dRKT0lo Oo8RsH5mrmUGdSrcyp3ZoAxABdhb0iCdR5VWI7TfJQIRAuO5zezIiBV77 c4N1AqrSSAgec4FIvIeTzvjCsuvzgwQLcpIMGziFtZClPx4awmfoSAMhD Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10537"; a="377705768" X-IronPort-AV: E=Sophos;i="5.96,180,1665471600"; d="scan'208";a="377705768" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2022 16:28:17 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10537"; a="729825557" X-IronPort-AV: E=Sophos;i="5.96,180,1665471600"; d="scan'208";a="729825557" Received: from tomnavar-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.209.176.15]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2022 16:28:13 -0800 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, 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, kai.huang@intel.com Subject: [PATCH v7 19/20] x86/virt/tdx: Flush cache in kexec() when TDX is enabled Date: Mon, 21 Nov 2022 13:26:41 +1300 Message-Id: X-Mailer: git-send-email 2.38.1 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750064164133493377?= X-GMAIL-MSGID: =?utf-8?q?1750064164133493377?= There are two problems in terms of using kexec() to boot to a new kernel when the old kernel has enabled TDX: 1) Part of the memory pages are still TDX private pages (i.e. metadata used by the TDX module, and any TDX guest memory if kexec() happens when there's any TDX guest alive). 2) There might be dirty cachelines associated with TDX private pages. Because the hardware doesn't guarantee cache coherency among different KeyIDs, the old kernel needs to flush cache (of those TDX private pages) before booting to the new kernel. Also, reading TDX private page using any shared non-TDX KeyID with integrity-check enabled can trigger #MC. Therefore ideally, the kernel should convert all TDX private pages back to normal before booting to the new kernel. However, this implementation doesn't convert TDX private pages back to normal in kexec() because of below considerations: 1) The kernel doesn't have existing infrastructure to track which pages are TDX private pages. 2) The number of TDX private pages can be large, and converting all of them (cache flush + using MOVDIR64B to clear the page) in kexec() can be time consuming. 3) The new kernel will almost only use KeyID 0 to access memory. KeyID 0 doesn't support integrity-check, so it's OK. 4) The kernel doesn't (and may never) support MKTME. If any 3rd party kernel ever supports MKTME, it should do MOVDIR64B to clear the page with the new MKTME KeyID (just like TDX does) before using it. Therefore, this implementation just flushes cache to make sure there are no stale dirty cachelines associated with any TDX private KeyIDs before booting to the new kernel, 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. Also, the current TDX module doesn't play nicely with kexec(). The TDX module can only be initialized once during its lifetime, and there is no ABI to reset the module to give a new clean slate to the new kernel. Therefore ideally, if the TDX module is ever initialized, it's better to shut it down. 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, shutting down the TDX module requires all CPUs being in VMX operation, but there's no such guarantee as kexec() can happen at any time (i.e. when KVM is not even loaded). So just do nothing but leave leave the TDX module open. Reviewed-by: Isaku Yamahata Signed-off-by: Kai Huang --- v6 -> v7: - Improved changelog to explain why don't convert TDX private pages back to normal. --- arch/x86/kernel/process.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index c21b7347a26d..0cc84977dc62 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -765,8 +765,14 @@ 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 its 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 (;;) { /*