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 28249C83013 for ; Wed, 2 Jul 2025 09:47:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD1DD6B00AD; Wed, 2 Jul 2025 05:47:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B83C96B00B8; Wed, 2 Jul 2025 05:47:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A71DC6B00C3; Wed, 2 Jul 2025 05:47:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 907BF6B00AD for ; Wed, 2 Jul 2025 05:47:42 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 56CEE5B7C5 for ; Wed, 2 Jul 2025 09:47:42 +0000 (UTC) X-FDA: 83618847564.27.5C0B4A9 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by imf21.hostedemail.com (Postfix) with ESMTP id 9C1891C0009 for ; Wed, 2 Jul 2025 09:47:39 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fyhjKVqI; spf=none (imf21.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.18) smtp.mailfrom=kirill.shutemov@linux.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=1751449660; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+Sexd7bX+ZklCc2hc1kvyKjqTnGBnOR2aVU1PixB9ks=; b=dKJ032Xq6UIjtl0yiOgB2f7GUqJbEgFD25rxGTqpR4w0miiHeJC1uSgqmodeP2QS4ad6+E qCvvmmgKdXus3bXufPAmv3GexBLx9cbRoRNL5g+rEVC3X2jZZ6hXAY4APrZAQjVDoGn3hm N3gwQDK7ZE9jSADPmYKG/uVfFSzmqf4= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fyhjKVqI; spf=none (imf21.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.18) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751449660; a=rsa-sha256; cv=none; b=Z+er9AsY1NozrUZSlgZ5KYux+MpdRrJm8dyLHhUehYkVGri7B/2c4f/8lAWjiStnVuB54q Gh7mj8uPiSMLlXbDX6raYvR5J+oB0o9lYn6PlAh9heqNQEPxCf6xCWGHYOf0Tla5crY0GC y8OWzaOWg1X0v2ZcG8Sl3a/mvAUClUQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751449660; x=1782985660; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=QquxLZIFBNYCLtfN2WN90KA9i4NdGTFGsp2moSfYXE4=; b=fyhjKVqIUkxJb1JKT2G3z8DrvoAhm64ajH18/4AL9eTwL4sKR3L+zEKd WoFJzqiZoqsYj38FYd6ATJhl9wx/7FLhganpuoIRJlY/WMG7w3PwszVJ+ RiPR798CF8rF+OMhUYRiQxTxTaDxOdxiea7AXahS0cnzjM4XYTjPdA2YJ 2IP7EnC/O8XcZ/C+Xvhq+j1/b88dxgCRLZU8RSQrJPSYr5UbEaQCeSuMq HvghIS88wu+qdatejZ4yU9L7LBkEMDVGccJssUVtKrvBpf41yjvxHCK4n RP9nrxGvm1gjtav27jhE7dioWsRgoFik+H+uU3nzCEilEWI2M9iu4K026 Q==; X-CSE-ConnectionGUID: HUizC5UCRfmhG1Ytbod7uA== X-CSE-MsgGUID: HKoAKUFjS3mATdX9vlF95g== X-IronPort-AV: E=McAfee;i="6800,10657,11481"; a="52968109" X-IronPort-AV: E=Sophos;i="6.16,281,1744095600"; d="scan'208";a="52968109" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2025 02:47:38 -0700 X-CSE-ConnectionGUID: LkxK1xTYTBadfjlqZ0+zdg== X-CSE-MsgGUID: kgMQFbTfRx2+ltJURfIKBQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,281,1744095600"; d="scan'208";a="154180676" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa007.jf.intel.com with ESMTP; 02 Jul 2025 02:47:26 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 427B11E0; Wed, 02 Jul 2025 12:47:24 +0300 (EEST) Date: Wed, 2 Jul 2025 12:47:24 +0300 From: "Kirill A. Shutemov" To: Sohil Mehta Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin , Jonathan Corbet , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv8 04/17] x86/cpu: Defer CR pinning setup until after EFI initialization Message-ID: <5s25fkpxv6p3ai2iagtgyqhpt3c4cv54q6lgeeebizsseediyy@wl4epcc7i35a> References: <20250701095849.2360685-1-kirill.shutemov@linux.intel.com> <20250701095849.2360685-5-kirill.shutemov@linux.intel.com> <080df169-0f47-40ea-b7b3-4d1a35bee151@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <080df169-0f47-40ea-b7b3-4d1a35bee151@intel.com> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9C1891C0009 X-Stat-Signature: fsiyasdm91g9x9enu1jusnkb83upxmxz X-Rspam-User: X-HE-Tag: 1751449659-814656 X-HE-Meta: U2FsdGVkX1+EQpQl1q7FucICbtCg0WGpKHe8NRJsbW/dnigx3BZFkgi9Ivs9svanMrofN9vM8GjEVOWdX4duDYg6sTnB6IIp7J0UQyHSSWFiOQTeYzn+hSiA3anf+3OPhIOmRHSKq9U8w7nanhQBXL6a1HYkSrm1Vgm24hdeXoKNOgqFdMbenSODpeT0vqt3CvuWUcnfssrWIiEN3r5+BayKtSb3zjLk2dSgiu/0kzu23Xz3/vEawfD/WsxmzD7Hp+fXS8B7bGXxBfUkDDJG+G9DhuUgNhqlTqIp5Pn1KIsDvnt+MsZWJSKEJyQj5zEQb3neY9oDhOPUg7McrXYmx461FicTAh04LfbQDEOo3xN0Gtqy03McCcgmQ/wbP4WSKSFxU5SJ6sh3CoW0FMa/1On5UKJQJ2ahlXs7ucUcNGVwnKIn+PCSUR2tYYK3ver0TsGCkkfkGC4OcxeyIgXUhLOd6ng4mSxJYzsDHfte7NJ0sTcGfekrHNSoC5x3/vL9DmOad0K2dNq7p9J5g6HRzO1+vNCcczzRHoWNdjp1QVmIqOZVKNul5CVDR0UQ/CNGpAhDoc0e0IU//y/4fzws+3Bc5RmNl7WQJQbLyQoWpDOtQYuhfBQjnbiceEFydV6GaFcxdK+0StQkoEzk4gNz0O2g0bfYPoj9qFtbWs3GVBAW3Lfi4hrvTQvpYfXcVPA0VgzL3QCbHhVjS711obVNFht80pBtOCmLPcLhdH4/179R4JI72HqiYvkeJnWyT8WzgdVwUBKY2jCTrBSXvZ/k+ohlHdG6JQr23YA6aKVGKpiLuk2wOUZpkpDiouJyf020D0HnOQqrNJ5t0Nw1iZzmH+L7NtQmukA68NkJuh/dpJ2DVRxHOdpUkFKzzVKnyN7d2wP1NoZ9nPZUMfRQ1arQexvDWd6AsUPOH7Qb/4UeG08BdSuUHS0am0P+/v91IlAYv68G+WsYgOjpdhiNOxr AtJAdHpg gOIhfNt2rHHygAyEJPZPxvcmCexFjqiirSa0QXeBCIy6PAqBbF039vWsMJ1pZiLB3HwDJn6hvpIriFdVIlx+t6PzO0pEfv2Bl7onXwyB02MTGxOJms4em9MvKaMIgW5HW8faDlvPu4TeybIVHWAf6tTYogkInuHLmiWqeyq902BWroQ828oeNekPpC85CPPsZ3vMc2JbRF8l56mk3DcfisZkWJSSGdt2T3oTdvSxjnsgyKud2suJgvgCv5+kGxqcfWuMPsgSNqAFIMJTWF+1WZ1mSWa5gGAjdO9SrGaYfTnzhPt2qMq9iehNqPF49/6Cy7zEw 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: List-Subscribe: List-Unsubscribe: On Tue, Jul 01, 2025 at 12:03:01PM -0700, Sohil Mehta wrote: > On 7/1/2025 2:58 AM, Kirill A. Shutemov wrote: > > From: Alexander Shishkin > > > > In order to map the EFI runtime services, set_virtual_address_map() > > needs to be called, which resides in the lower half of the address > > space. This means that LASS needs to be temporarily disabled around > > this call. This can only be done before the CR pinning is set up. > > > > Move CR pinning setup behind the EFI initialization. > > > > Wrapping efi_enter_virtual_mode() into lass_disable/enable_enforcement() > > I believe this should be lass_stac()/clac() since we reverted to the > original naming. Doh. Will fix. > > is not enough because AC flag gates data accesses, but not instruction > > fetch. Clearing the CR4 bit is required. > > > > Signed-off-by: Alexander Shishkin > > Suggested-by: Kirill A. Shutemov > > Signed-off-by: Kirill A. Shutemov > > --- > > arch/x86/kernel/cpu/common.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > > index 4f430be285de..9918121e0adc 100644 > > --- a/arch/x86/kernel/cpu/common.c > > +++ b/arch/x86/kernel/cpu/common.c > > @@ -2081,7 +2081,6 @@ static __init void identify_boot_cpu(void) > > enable_sep_cpu(); > > #endif > > cpu_detect_tlb(&boot_cpu_data); > > - setup_cr_pinning(); > > > > tsx_init(); > > tdx_init(); > > @@ -2532,10 +2531,14 @@ void __init arch_cpu_finalize_init(void) > > > > /* > > * This needs to follow the FPU initializtion, since EFI depends on it. > > + * > > + * EFI twiddles CR4.LASS. Do it before CR pinning. > > */ > > if (efi_enabled(EFI_RUNTIME_SERVICES)) > > efi_enter_virtual_mode(); > > > > + setup_cr_pinning(); > > + > > Instead of EFI toggling CR4.LASS, why not defer the first LASS > activation itself? > > i.e. > > if (efi_enabled(EFI_RUNTIME_SERVICES)) > efi_enter_virtual_mode(); > > setup_lass(); > > setup_cr_pinning(); > > > This way, we can avoid the following patch (#5) altogether. That's definitely an option. The benefit of current approach is that the enforcement is enabled earlier and cover more boot code, providing marginal protection improvement. I also like that related security features (SMEP/SMAP/UMIP/LASS) are enabled in the same place. In the end it is a judgement call. Maintainers, any preference? -- Kiryl Shutsemau / Kirill A. Shutemov