From nobody Wed Apr 15 16:43:46 2026 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C2DCB25A645; Tue, 3 Mar 2026 23:59:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772582361; cv=none; b=qkeA/swSvJdwQx462juEaClC+SNNNNxWwMQ4gGW/I+8HfAgOiuWcUmFPKkWcHMq4SvdL1ZthJdzRc/YShJcYQSUUqhZgBF75CZjb9Jkhf34mCPDqXyi60jOl5UDU2WgxbnV6Xsk8ry0HzJcLajHXduMTKMVZfX1Ps7jTOh504+0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772582361; c=relaxed/simple; bh=AnfsRfS0oAyDgiIbyNBI4rFFX1CQSr0LDNhoHiPlbN4=; h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version: Message-ID:Content-Type; b=P7ww/qf4ReudTr81LppSU9NMwsRaEnxdrz83MPF49WgwyEw/X4FvMbGcVUgs3Et3oD6f/u0uKnyjAhKvF7K55DGdthfrqGAqBbcr/TPlurCmD/6xE1UzDfynj+MOahNnNUtwAj8n9oUk//aQNwYAE2V0HVtFOveaGXXLnUBebkQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=pEg+QUjE; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=eQxrX+71; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="pEg+QUjE"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="eQxrX+71" Date: Tue, 03 Mar 2026 23:59:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1772582357; h=from:from:sender:sender:reply-to: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; bh=+MCGU5+GjnkfOl5W1uhSF/StfjY+oXsC0Ze7KMfzb9Q=; b=pEg+QUjEvu+4CIihYMpMsX0cS4//iir2zJjxz/c8Mvq81lGGkcJjiPtmZe77QTawklIulb bXazRBHPLXAfD2f35+xKqRcUpyE+SxGzFMluSw57+nlJGURtHSM31S4IQNW5M2oypUxYE6 ApIpFsHOjM2rL2xFKD35Dco3rNGGe+gGwkOpUdvYD2JpVzzgZai0xPRVi7ye9Nh9i7YaQ9 6c1WF0HnND+HtLKpPwN01ka4WK+X0aiX5tykTJP+f6BZQW+55BOxHM4XgtWontfCdTAqiQ Fcyijpx7bnkgpNml1nIuYVEojXGtrLbz8bU6xVu3MbK5WvJ8v+EHOAta81gaTw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1772582357; h=from:from:sender:sender:reply-to: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; bh=+MCGU5+GjnkfOl5W1uhSF/StfjY+oXsC0Ze7KMfzb9Q=; b=eQxrX+71aaqUEMI8gC5i4Ao7afLzLoj5hpuC40d+e7URwBUgYJuhUelct/vrxMMw4b6Kly 0zYOCzy4fmv6CuBw== From: "tip-bot2 for Sohil Mehta" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/cpu] x86/cpu: Defer LASS enabling until userspace comes up Cc: Sohil Mehta , Dave Hansen , Tony Luck , "Maciej Wieczor-Retman" , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20260120234730.2215498-2-sohil.mehta@intel.com> References: <20260120234730.2215498-2-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <177258235654.1647592.8186200667919618122.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The following commit has been merged into the x86/cpu branch of tip: Commit-ID: b3226af5ad7bbfcba79d26f547fe6582baf20ce9 Gitweb: https://git.kernel.org/tip/b3226af5ad7bbfcba79d26f547fe6582b= af20ce9 Author: Sohil Mehta AuthorDate: Tue, 20 Jan 2026 15:47:28 -08:00 Committer: Dave Hansen CommitterDate: Tue, 03 Mar 2026 09:49:44 -08:00 x86/cpu: Defer LASS enabling until userspace comes up LASS blocks any kernel access to the lower half of the virtual address space. Unfortunately, some EFI accesses happen during boot with bit 63 cleared, which causes a #GP fault when LASS is enabled. Notably, the SetVirtualAddressMap() call can only happen in EFI physical mode. Also, EFI_BOOT_SERVICES_CODE/_DATA could be accessed even after ExitBootServices(). The boot services memory is truly freed during efi_free_boot_services() after SVAM has completed. To prevent EFI from tripping LASS, at a minimum, LASS enabling must be deferred until EFI has completely finished entering virtual mode (including freeing boot services memory). Moving setup_lass() to arch_cpu_finalize_init() would do the trick, but that would make the implementation very fragile. Something else might come in the future that would need the LASS enabling to be moved again. In general, security features such as LASS provide limited value before userspace is up. They aren't necessary during early boot while only trusted ring0 code is executing. Introduce a generic late initcall to defer activating some CPU features until userspace is enabled. For now, only move the LASS CR4 programming to this initcall. As APs are already up by the time late initcalls run, some extra steps are needed to enable LASS on all CPUs. Use a CPU hotplug callback instead of on_each_cpu() or smp_call_function(). This ensures that LASS is enabled on every CPU that is currently online as well as any future CPUs that come online later. Note, even though hotplug callbacks run with preemption enabled, cr4_set_bits() would disable interrupts while updating CR4. Keep the existing logic in place to clear the LASS feature bits early. setup_clear_cpu_cap() must be called before boot_cpu_data is finalized and alternatives are patched. Eventually, the entire setup_lass() logic can go away once the restrictions based on vsyscall emulation and EFI are removed. Signed-off-by: Sohil Mehta Signed-off-by: Dave Hansen Tested-by: Tony Luck Tested-by: Maciej Wieczor-Retman Link: https://patch.msgid.link/20260120234730.2215498-2-sohil.mehta@intel.c= om --- arch/x86/kernel/cpu/common.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 1c3261c..8c56d59 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -422,11 +422,32 @@ static __always_inline void setup_lass(struct cpuinfo= _x86 *c) if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION) || IS_ENABLED(CONFIG_EFI)) { setup_clear_cpu_cap(X86_FEATURE_LASS); - return; } +} =20 +static int enable_lass(unsigned int cpu) +{ cr4_set_bits(X86_CR4_LASS); + + return 0; +} + +/* + * Finalize features that need to be enabled just before entering + * userspace. Note that this only runs on a single CPU. Use appropriate + * callbacks if all the CPUs need to reflect the same change. + */ +static int cpu_finalize_pre_userspace(void) +{ + if (!cpu_feature_enabled(X86_FEATURE_LASS)) + return 0; + + /* Runs on all online CPUs and future CPUs that come online. */ + cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/lass:enable", enable_lass, NU= LL); + + return 0; } +late_initcall(cpu_finalize_pre_userspace); =20 /* These bits should not change their value after CPU init is finished. */ static const unsigned long cr4_pinned_mask =3D X86_CR4_SMEP | X86_CR4_SMAP= | X86_CR4_UMIP |