From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 069F322A7E0; Tue, 7 Oct 2025 06:53:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820040; cv=none; b=Hw7vA0CHkldZR9nP3OuJq40aYPJJPiIRZkSO2J9a20+siUcmd3r0KMN33lHLVA+APrJEcSRJLtnqggax3GE4DP31uXf2e2VqZdb66xXzR9o9gz05Paea7jha5/rQYupiFxKRySmcV58I2R6DlCTqwYnHLDR6Ptxw+WQr4dHpVSc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820040; c=relaxed/simple; bh=4N/ktkwoSE/cm5M0B9yQP4RXULxVaZNEE+v/jC6bd5g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HBwqUi0ypJ/i5yiN2UutP0m2VTuMeIhyY5EPl84TD7faozgUrXk0rMnXwQ1Yud3fKkzn0hKvFP5fJ8Qbb4xadJK6bIPkAjvNRvfAimTUyHA5a0RQuqTHX8LR0VToPtBrxT9qlrax8hqtGv6tnRiYnrjyHDgfEdjhkIqst0IvX4o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=K+acjty+; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="K+acjty+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820038; x=1791356038; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=4N/ktkwoSE/cm5M0B9yQP4RXULxVaZNEE+v/jC6bd5g=; b=K+acjty+Y78GcTPLbFR+fjwbIEeaKWKXnhTbJyceyOjCQjBGow/yQmRC qipqo+jQHUEwwUfe2OAkAsHe5kLOxEV49tivElYdDzmGd5w3MIko0yfXa Jiq1yyyIlSbvchA92GAuNPPNvKE12wRpTl2+O2iVn/Xke4+ekFthWl4yw weSb3pJghDqyfY1T7HqAgjzHFboiqAqO47HWkdvJyIE+LZZnYokBpQSKl qF5Ni5DL88FnAuppS6MRaHW6SQN181u2dxn2iT6Y4vNrOteWXi+3QucsK wcbySxD0prFG+QCTSka/yti653aoEbVNEnj99kXne5xje8MNT2HcpMf57 A==; X-CSE-ConnectionGUID: EzgN6OugROulQmOH+3g1lg== X-CSE-MsgGUID: QdZ39y5kQ2O9+99YzN/fOg== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254387" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254387" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:53:56 -0700 X-CSE-ConnectionGUID: LMRMWWtuRHG4Els7b6KfKw== X-CSE-MsgGUID: tVe1ucdQSjSKaDssIHSvgQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354460" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:53:56 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 01/15] x86/cpu: Enumerate the LASS feature bits Date: Mon, 6 Oct 2025 23:51:05 -0700 Message-ID: <20251007065119.148605-2-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Linear Address Space Separation (LASS) is a security feature that intends to prevent malicious virtual address space accesses across user/kernel mode. Such mode based access protection already exists today with paging and features such as SMEP and SMAP. However, to enforce these protections, the processor must traverse the paging structures in memory. An attacker can use timing information resulting from this traversal to determine details about the paging structures, and to determine the layout of the kernel memory. LASS provides the same mode-based protections as paging but without traversing the paging structures. Because the protections are enforced pre-paging, an attacker will not be able to derive paging-based timing information from the various caching structures such as the TLBs, mid-level caches, page walker, data caches, etc. LASS enforcement relies on the kernel implementation to divide the 64-bit virtual address space into two halves: Addr[63]=3D0 -> User address space Addr[63]=3D1 -> Kernel address space Any data access or code execution across address spaces typically results in a #GP fault. The LASS enforcement for kernel data accesses is dependent on CR4.SMAP being set. The enforcement can be disabled by toggling the RFLAGS.AC bit similar to SMAP. Define the CPU feature bits to enumerate LASS and add a dependency on SMAP. LASS mitigates a class of side-channel speculative attacks, such as Spectre LAM [1]. Add the "lass" flag to /proc/cpuinfo to indicate that the feature is supported by hardware and enabled by the kernel. This allows userspace to determine if the system is secure against such attacks. Link: https://download.vusec.net/papers/slam_sp24.pdf [1] Signed-off-by: Sohil Mehta Reviewed-by: Borislav Petkov (AMD) Reviewed-by: Xin Li (Intel) --- v10: - Do not modify tools/**/cpufeatures.h as those are synced separately. --- arch/x86/Kconfig.cpufeatures | 4 ++++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/uapi/asm/processor-flags.h | 2 ++ arch/x86/kernel/cpu/cpuid-deps.c | 1 + 4 files changed, 8 insertions(+) diff --git a/arch/x86/Kconfig.cpufeatures b/arch/x86/Kconfig.cpufeatures index 250c10627ab3..733d5aff2456 100644 --- a/arch/x86/Kconfig.cpufeatures +++ b/arch/x86/Kconfig.cpufeatures @@ -124,6 +124,10 @@ config X86_DISABLED_FEATURE_PCID def_bool y depends on !X86_64 =20 +config X86_DISABLED_FEATURE_LASS + def_bool y + depends on X86_32 + config X86_DISABLED_FEATURE_PKU def_bool y depends on !X86_INTEL_MEMORY_PROTECTION_KEYS diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpuf= eatures.h index b2a562217d3f..1283f3bdda0d 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -314,6 +314,7 @@ #define X86_FEATURE_SM4 (12*32+ 2) /* SM4 instructions */ #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* "avx_vnni" AVX VNNI instructio= ns */ #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* "avx512_bf16" AVX512 BFLOAT= 16 instructions */ +#define X86_FEATURE_LASS (12*32+ 6) /* "lass" Linear Address Space Separa= tion */ #define X86_FEATURE_CMPCCXADD (12*32+ 7) /* CMPccXADD instructio= ns */ #define X86_FEATURE_ARCH_PERFMON_EXT (12*32+ 8) /* Intel Architectural Per= fMon Extension */ #define X86_FEATURE_FZRM (12*32+10) /* Fast zero-length REP MOVSB */ diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include= /uapi/asm/processor-flags.h index f1a4adc78272..81d0c8bf1137 100644 --- a/arch/x86/include/uapi/asm/processor-flags.h +++ b/arch/x86/include/uapi/asm/processor-flags.h @@ -136,6 +136,8 @@ #define X86_CR4_PKE _BITUL(X86_CR4_PKE_BIT) #define X86_CR4_CET_BIT 23 /* enable Control-flow Enforcement Technology = */ #define X86_CR4_CET _BITUL(X86_CR4_CET_BIT) +#define X86_CR4_LASS_BIT 27 /* enable Linear Address Space Separation supp= ort */ +#define X86_CR4_LASS _BITUL(X86_CR4_LASS_BIT) #define X86_CR4_LAM_SUP_BIT 28 /* LAM for supervisor pointers */ #define X86_CR4_LAM_SUP _BITUL(X86_CR4_LAM_SUP_BIT) =20 diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-d= eps.c index 46efcbd6afa4..98d0cdd82574 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -89,6 +89,7 @@ static const struct cpuid_dep cpuid_deps[] =3D { { X86_FEATURE_SHSTK, X86_FEATURE_XSAVES }, { X86_FEATURE_FRED, X86_FEATURE_LKGS }, { X86_FEATURE_SPEC_CTRL_SSBD, X86_FEATURE_SPEC_CTRL }, + { X86_FEATURE_LASS, X86_FEATURE_SMAP }, {} }; =20 --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 36A7E22D4D3; Tue, 7 Oct 2025 06:53:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820041; cv=none; b=HQx6qppgbTuxxjVY+y+r35qaEujKPRQfkBGLjf4LtBWHVPbl8QjwzRz1B2oRLCf8/IWexVmg3SjxgTILeItm9qWffvXtTORbax9JYw62fcCI+4L6XvYnJvn+5zrds3fAxcTP0Yz9wlQqckleJyPm8BENfvvqpa1+02nw85Iu5IY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820041; c=relaxed/simple; bh=B3Yt3zm5Pr0yTCY/kUb8onQVol3RsVdueR6rzjWl9/E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PA06VBz/V7hCNvBxw7sTynlDlcBbIq2C/0j5fQpgDG7vo+6VJ1LQxkKmB2wC/FmO5WO0zXLetaglWMDnhykrTuz38ciOULDrWdFI4lVF2vvtiSe8/AB+gy7giKnBpqZnwSZToJgFKRWrJtM3tFFKNTI1KDcrJZhbC2ng6SEBgc4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=NB3kRr8V; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="NB3kRr8V" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820039; x=1791356039; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=B3Yt3zm5Pr0yTCY/kUb8onQVol3RsVdueR6rzjWl9/E=; b=NB3kRr8VOJ2rLxiCHkVTYcTDV3y0LbvS9K0AMGzi30RF5dHRojj7mpYQ Td/ilSa9Cqjk6h71zxb8zx9I++7qwxp1O2yj/MYDkIAbTFTvr17DkytdK yIG9mAuFHKWixIAhZj1hirOFTgTG4Ap7TlE5PPLPLiGlRQd80bETOwlt3 eIcrJqJ/t1APPD3DAKtpnrcLp7md78Z1UbuHaMrBj7uAGFIEk0XMBxLV2 frcqUiZFIZoR36nssIEQXrXETirjf1PRGnjg0uF1W4agp4N1dOv+c5Xyu c+JhqeZ0SFM4KqHVTcK33BaXJCMRqNoqJDUj0mkyEwJB1pp1/kyb8Y8rx A==; X-CSE-ConnectionGUID: zmXTtpuwQ5GslTn7QXNFgA== X-CSE-MsgGUID: pLGqOLpeTyaW1o/xNDJ2ag== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254403" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254403" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:53:57 -0700 X-CSE-ConnectionGUID: rdbhJkAPQBCs6AfnmC+ESg== X-CSE-MsgGUID: 3Ih2UZGCRg6LfApYKm6GFg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354465" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:53:57 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 02/15] x86/asm: Introduce inline memcpy and memset Date: Mon, 6 Oct 2025 23:51:06 -0700 Message-ID: <20251007065119.148605-3-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Peter Zijlstra (Intel)" Provide inline memcpy and memset functions that can be used instead of the GCC builtins when necessary. The immediate use case is for the text poking functions to avoid the standard memcpy()/memset() calls within an RFLAGS.AC=3D1 context. Some user copy functions such as copy_user_generic() and __clear_user() have similar rep_{movs,stos} usages. But, those are highly specialized and hard to combine/reuse for other things. Define these new helpers for all other usages that need a completely unoptimized, strictly inline version of memcpy() or memset(). Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Sohil Mehta --- v10: - Reintroduce the simpler inline patch (dropped in v8). --- arch/x86/include/asm/string.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h index c3c2c1914d65..9cb5aae7fba9 100644 --- a/arch/x86/include/asm/string.h +++ b/arch/x86/include/asm/string.h @@ -1,6 +1,32 @@ /* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_X86_STRING_H +#define _ASM_X86_STRING_H + #ifdef CONFIG_X86_32 # include #else # include #endif + +static __always_inline void *__inline_memcpy(void *to, const void *from, s= ize_t len) +{ + void *ret =3D to; + + asm volatile("rep movsb" + : "+D" (to), "+S" (from), "+c" (len) + : : "memory"); + return ret; +} + +static __always_inline void *__inline_memset(void *s, int v, size_t n) +{ + void *ret =3D s; + + asm volatile("rep stosb" + : "+D" (s), "+c" (n) + : "a" ((uint8_t)v) + : "memory"); + return ret; +} + +#endif /* _ASM_X86_STRING_H */ --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 979FE82866; Tue, 7 Oct 2025 06:53:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820041; cv=none; b=UBsTyKg97Pw2V+48xk5/r7qZirZxgqC6zDEloZMXsbVa9G4sK0C0AYhI2kHfUE4Co0AQcmTmWo6yELp4qg+NDeMUN4QlNcn+0QFb4eFx+X2NCW6wnJpJgRLkG236fsrXgmvNfwP5Nc+DdVU4Vk/asE5CucvnlAZNSkod3GG4igM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820041; c=relaxed/simple; bh=Xe1JDPucIxQIhHiVPqvH+i1PVjohP3EYCdrPV9RmZEE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aUaKgna1wob6ji6G+FtykQvj5BBW0JzS4bXxgu2Baej/B3BH5hOqwvUHHIZN3O38iN9zoe2NHsHiBr23XdQ46AYD7R0mVQ1sjvuNA0OzXbrSu4AqeN04ilP/0KYMTsuQfefFYA0sNNMH8HTCw6MmorLaFdtOIl2WqT2xfMTXZD4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Y4rh5EWU; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Y4rh5EWU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820039; x=1791356039; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Xe1JDPucIxQIhHiVPqvH+i1PVjohP3EYCdrPV9RmZEE=; b=Y4rh5EWUtiCZaOxwCqI0piLWPIs7pf9FVTQKEa8lnsnhdACpdBKfwnSU MPG8nf1xissO3FUIsvi9g6ZC+2121LdPaJZ18EbdFxOK+ulMb5W0Ry48E IqG3gZerMgveOXaNz2QLordTK+/dmzJpn0efEOhN82WOGDiVy2WTafUZ5 G/RLVKgCPx47Ka6ZduuVMR90ZSrAZY9KwRf8rmMLWKfpph+f685UabQXl HIuiz3CKo+ahX80r74EEO4tp+bZk8YmwBFkGYjS+2Pemn1m8eRLjkNu2c n4jf+CIJNIXCEWUjQzunZQ5qvxSjG3no2FSJ7kqJi37w0u0nxIkkZNt3Z Q==; X-CSE-ConnectionGUID: UnoBXe4OTXC38TrOiqfFyA== X-CSE-MsgGUID: 62OxOoG+Q86vqA3cCAZ8Vw== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254418" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254418" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:53:58 -0700 X-CSE-ConnectionGUID: IKJ8wIuJRKehU57wuQbKug== X-CSE-MsgGUID: n87D1ICVSdqkVTwkww7imA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354469" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:53:57 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 03/15] x86/alternatives: Disable LASS when patching kernel alternatives Date: Mon, 6 Oct 2025 23:51:07 -0700 Message-ID: <20251007065119.148605-4-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For patching, the kernel initializes a temporary mm area in the lower half of the address range. Disable LASS enforcement by toggling the RFLAGS.AC bit during patching to avoid triggering a #GP fault. Introduce LASS-specific stac()/clac() helpers along with comments to clarify their usage versus the existing stac()/clac() helpers for SMAP. Text poking functions used while patching kernel alternatives use the standard memcpy()/memset(). However, objtool complains about calling dynamic functions within an AC=3D1 region. One workaround is to add memcpy() and memset() to the list of functions allowed by objtool. However, that would provide a blanket exemption for all usages of memcpy() and memset(). Instead, replace the standard memcpy() and memset() calls in the text poking functions with their unoptimized inline versions. Considering that patching is usually small, there is no performance impact expected. Signed-off-by: Sohil Mehta --- v10: - Revert to the inline functions instead of open-coding in assembly. - Simplify code comments. --- arch/x86/include/asm/smap.h | 35 +++++++++++++++++++++++++++++++++-- arch/x86/kernel/alternative.c | 18 ++++++++++++++++-- 2 files changed, 49 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/smap.h b/arch/x86/include/asm/smap.h index 4f84d421d1cf..3ecb4b0de1f9 100644 --- a/arch/x86/include/asm/smap.h +++ b/arch/x86/include/asm/smap.h @@ -23,18 +23,49 @@ =20 #else /* __ASSEMBLER__ */ =20 +/* + * The CLAC/STAC instructions toggle the enforcement of X86_FEATURE_SMAP + * and X86_FEATURE_LASS. + * + * SMAP enforcement is based on the _PAGE_BIT_USER bit in the page + * tables. The kernel is not allowed to touch pages with the bit set + * unless the AC bit is set. + * + * Use stac()/clac() when accessing userspace (_PAGE_USER) mappings, + * regardless of location. + * + * Note: a barrier is implicit in alternative(). + */ + static __always_inline void clac(void) { - /* Note: a barrier is implicit in alternative() */ alternative("", "clac", X86_FEATURE_SMAP); } =20 static __always_inline void stac(void) { - /* Note: a barrier is implicit in alternative() */ alternative("", "stac", X86_FEATURE_SMAP); } =20 +/* + * LASS enforcement is based on bit 63 of the virtual address. The + * kernel is not allowed to touch memory in the lower half of the + * virtual address space unless the AC bit is set. + * + * Use lass_stac()/lass_clac() when accessing kernel mappings + * (!_PAGE_USER) in the lower half of the address space. + */ + +static __always_inline void lass_clac(void) +{ + alternative("", "clac", X86_FEATURE_LASS); +} + +static __always_inline void lass_stac(void) +{ + alternative("", "stac", X86_FEATURE_LASS); +} + static __always_inline unsigned long smap_save(void) { unsigned long flags; diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index 79ae9cb50019..dc90b421d760 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -2409,16 +2409,30 @@ void __init_or_module text_poke_early(void *addr, c= onst void *opcode, __ro_after_init struct mm_struct *text_poke_mm; __ro_after_init unsigned long text_poke_mm_addr; =20 +/* + * Text poking creates and uses a mapping in the lower half of the + * address space. Relax LASS enforcement when accessing the poking + * address. + * + * Also, objtool enforces a strict policy of "no function calls within + * AC=3D1 regions". Adhere to the policy by using inline versions of + * memcpy()/memset() that will never result in a function call. + */ + static void text_poke_memcpy(void *dst, const void *src, size_t len) { - memcpy(dst, src, len); + lass_stac(); + __inline_memcpy(dst, src, len); + lass_clac(); } =20 static void text_poke_memset(void *dst, const void *src, size_t len) { int c =3D *(const int *)src; =20 - memset(dst, c, len); + lass_stac(); + __inline_memset(dst, c, len); + lass_clac(); } =20 typedef void text_poke_f(void *dst, const void *src, size_t len); --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 A5C8F235341; Tue, 7 Oct 2025 06:54:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820042; cv=none; b=sDLfQRBCQvmy8lrqcDz5cRqMSBE6HOZGllm5ZbtVPKnYsf5qO+IPPn3l2VjcVf3ioi0pVMJOtwvzlDK9Dd+MNDIyA0yL5PpU5oVVM65z/hjNmUr4mBYyfvEoQVqyBrHqLz0jIP0meRJTByy+QDrbKJvk2WI/8xBU74KunJgw9jI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820042; c=relaxed/simple; bh=r46GE5fcmXJUOsOhFrhC0/yII78h6bGgbcDsW3hMsiY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dkVQnYWJauVGIFCvz1FMW7ZoN2sf8Plym/r+z0hhqvP2YWNRYo3xVDqyC0temFrqX3tGcjepVcCWAH6v3llHBXDsuWiqEmZRt5A6Cp2oBECdUWUs7q5jElXxRCt6u0uaLbuDepsEJSjaTkozNwfqgoMFKmfni9KlNKvtsPsxPvU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=jFdMTPzv; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="jFdMTPzv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820040; x=1791356040; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=r46GE5fcmXJUOsOhFrhC0/yII78h6bGgbcDsW3hMsiY=; b=jFdMTPzvz+o79YP//gZyUCb6O5uEA+s44a5nI7cO9qoMZ15xom8WHgJa ZyqMTheMmx02OtFjbQtadtgQV4JWevy6+JJluwyBkZyoVIgx8iV5I8Uy4 a0DlINYy4aFNrlBWNhEX8rQnMtTVT6slQvXiz9gBHyTqCxI5jttdlHEZ8 oH172HNGqmOAFy311HO2AD3XvkJeu35s7I9QqRVrEBRRzhJ3iml2cfh+8 qniCqYmKoLmwPJrt5h72kD3duNDJkDY5D8LjYzYseKkb+G8XCrhy7poLW PwSY78WQ3Zv2eFp8Zr9RySJ6jh0mlNMX03Nqb3vHadKMQE1cnqouo1h5O w==; X-CSE-ConnectionGUID: WyHY2xdlROq+XsVXDEj68Q== X-CSE-MsgGUID: v/znFtYJTqKcsXf7ecxRYw== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254433" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254433" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:53:58 -0700 X-CSE-ConnectionGUID: l+d5GK6NQFWXa+3JX2RqmA== X-CSE-MsgGUID: BO7q1UogQ9u/zWbcfFux0g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354474" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:53:58 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 04/15] x86/cpu: Set LASS CR4 bit as pinning sensitive Date: Mon, 6 Oct 2025 23:51:08 -0700 Message-ID: <20251007065119.148605-5-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yian Chen Security features such as LASS are not expected to be disabled once initialized. Add LASS to the CR4 pinned mask. Signed-off-by: Yian Chen Signed-off-by: Sohil Mehta --- v10: - No change. --- arch/x86/kernel/cpu/common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index c7d3512914ca..61ab332eaf73 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -403,7 +403,8 @@ static __always_inline void setup_umip(struct cpuinfo_x= 86 *c) =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 | - X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED; + X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED | + X86_CR4_LASS; static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning); static unsigned long cr4_pinned_bits __ro_after_init; =20 --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 38D8F2367CC; Tue, 7 Oct 2025 06:54:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820043; cv=none; b=K7K0eOsyGupA0LyFtghl16RFRxMJkr3D9tEv8i4Lbrnl3ZOVjFCy9vhBVT62vKztH20dY7eIHPORTLNq61IKyOFC5LteggjUQDYbXx5+lZjA3BcYkqBq5Cf55VqiLPuyUsjUkXZHoPTMnHmnN60GUn98b9gOUu7bIPzib0WVgic= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820043; c=relaxed/simple; bh=He18mQTkB07VatWb7vSd19sKKa+uJJoTfhGyKuWZTIM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Tm84rgNNuMedOhEDYGesFwX8YfXuu9p5VHoQqAb0lSuget7zVOLBsa8jN7rWjy2S8OHjUsX2Nf1WMq1S1AJkq7Jre2ZV7BKDdSjEyDEHDbvTUC0Rxuz/fI105GyCW1+w+zmEGze57gNuIgVKWo1DqdnYvD9BvoCuB9xE7GQhVx0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=PELZYFA3; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="PELZYFA3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820041; x=1791356041; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=He18mQTkB07VatWb7vSd19sKKa+uJJoTfhGyKuWZTIM=; b=PELZYFA3IUsqpwdoaqg/O5/CxSo5JRLUdEfuI4dYNMJsYgGPb4OszxXU 1ZyJKYTbCg5DHniBC5rm6ij7GKGsgx3GZSW++EZ/M5XJmQRbc5ei20L0C qr9YwML6zJYKbhEf7CXSvUpNTWLiI1CR14ljchqMOS2e5M9pIOeBircdR hwY+iOx77BjIWVCkpGZZMt2xJosF0pxY2ALTqeebsrh2ENQMEcI0WepYt 33Tn9geDJ4S29wxfxivBZhx4xHtooPetdpjKARh79qDLEJ7rTZheR3gTd Wk7MQRg0UcOPk1nXfHjEygfISjP5cpG8yXjlC/wAaZSH177J8Mx+zlW1h A==; X-CSE-ConnectionGUID: cb/5hBwiRFeqOSHU2HTuLQ== X-CSE-MsgGUID: B0s64srmREGpjKFRV2OI4w== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254449" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254449" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:53:59 -0700 X-CSE-ConnectionGUID: JO6wmiYGSaaBJi85QqqdHQ== X-CSE-MsgGUID: RbnuZQ4mQBqlWW1xPblWTw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354480" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:53:59 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 05/15] x86/cpu: Defer CR pinning enforcement until late_initcall() Date: Mon, 6 Oct 2025 23:51:09 -0700 Message-ID: <20251007065119.148605-6-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Problem Suggested-by: Dave Hansen ------- 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. Wrapping efi_enter_virtual_mode() with lass_stac()/clac() is not enough, because the AC flag only gates data accesses, not instruction fetches. Clearing the CR4.LASS bit is required to make this work. However, pinned CR4 bits are not expected to be modified after boot CPU init, resulting in a kernel warning. Solution -------- One option is to move the CR pinning setup immediately after the runtime services have been mapped. However, that is a narrow fix that would require revisiting if something else needs to modify a pinned CR bit. CR pinning mainly prevents exploits from trivially modifying security-sensitive CR bits. There is limited benefit to enabling CR pinning before userspace comes up. Defer CR pinning enforcement until late_initcall() to allow EFI and future users to modify the CR bits without any concern for CR pinning. Save the pinned bits while initializing the boot CPU because they are needed later to program the value on APs when they come up. Note ---- This introduces a small window between the boot CPU being initialized and CR pinning being enforced, where any in-kernel clearing of the pinned bits could go unnoticed. Later, when enforcement begins, a warning is triggered as soon as any CR4 bit is modified, such as X86_CR4_PGE during a TLB flush. Currently, this is a purely theoretical concern. There are multiple ways to resolve it [1] if it becomes a problem in practice. Link: https://lore.kernel.org/lkml/c59aa7ac-62a6-45ec-b626-de518b25f7d9@int= el.com/ [1] Suggested-by: Dave Hansen Signed-off-by: Sohil Mehta --- v10: - Split recording pinned bits and enabling pinning into two functions. - Defer pinning until userspace comes up. This patch does not include any changes to harden the CR pinning implementation, as that is beyond the scope of this series. --- arch/x86/kernel/cpu/common.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 61ab332eaf73..57d5824465b0 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -476,8 +476,8 @@ void cr4_init(void) =20 if (boot_cpu_has(X86_FEATURE_PCID)) cr4 |=3D X86_CR4_PCIDE; - if (static_branch_likely(&cr_pinning)) - cr4 =3D (cr4 & ~cr4_pinned_mask) | cr4_pinned_bits; + + cr4 =3D (cr4 & ~cr4_pinned_mask) | cr4_pinned_bits; =20 __write_cr4(cr4); =20 @@ -487,14 +487,21 @@ void cr4_init(void) =20 /* * Once CPU feature detection is finished (and boot params have been - * parsed), record any of the sensitive CR bits that are set, and - * enable CR pinning. + * parsed), record any of the sensitive CR bits that are set. */ -static void __init setup_cr_pinning(void) +static void __init record_cr_pinned_bits(void) { cr4_pinned_bits =3D this_cpu_read(cpu_tlbstate.cr4) & cr4_pinned_mask; +} + +/* Enables enforcement of the CR pinned bits */ +static int __init enable_cr_pinning(void) +{ static_key_enable(&cr_pinning.key); + + return 0; } +late_initcall(enable_cr_pinning); =20 static __init int x86_nofsgsbase_setup(char *arg) { @@ -2119,7 +2126,7 @@ static __init void identify_boot_cpu(void) enable_sep_cpu(); #endif cpu_detect_tlb(&boot_cpu_data); - setup_cr_pinning(); + record_cr_pinned_bits(); =20 tsx_init(); tdx_init(); --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 8FF1F238150; Tue, 7 Oct 2025 06:54:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820043; cv=none; b=Ywq/H11/XiRjaM5U9VBJocPgwBVToxBXbDhJZEda2yyU2A5H/VBgVUS7TllYc8PRKIArdKPC2LKHlKCInYO70exv9MkSuZdE4zJbAXCgzRZhI5ieGPHq67kULpX9yidfOkBNasllmS7KBueHxrZgvfoeMFsRrxPS70jgKwAZFmA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820043; c=relaxed/simple; bh=2tLYylj3DF/5PX3moQnEXwNy+fnzilsriKy0eTjLYT0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hTaIfgS8grnrE2Du60RR4603ubo+VOz0IJDYScM1hxlzBR+5Oh/sJkFce9Fd0eIkNMI/bOF3ln2WWMxU2B78roKoFY3mifeO1HanQ9btDj8Tu3zOlzih4r8HPPOP3h+CiUCg6UoOIjKpG3H1hs4hCcXzwFf01SBMb9srVndSvPc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ffnAY8Vh; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ffnAY8Vh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820041; x=1791356041; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=2tLYylj3DF/5PX3moQnEXwNy+fnzilsriKy0eTjLYT0=; b=ffnAY8Vhq1wpyd6QRBJCbUR37NHMed9I/NaD4LN0OfUSMLUK7QNyT3pC ruR3X6YlQ1K2CtlU5ihvxrtjw+m2GeLOb4mKXCvREyT6SsYzufx7mqbuV 1qEKRwe7RhL42l9JGtTpTkEHv9GxQwfp0SbxEnjVoMjzP4/4xljy6ughS T/onDGw9pOBl4MuN+uvcto0SACJWXBmp+Y7b0EgAe/sgTTHBjNP1+jrI2 RGxEWFTT5/Pa3sEscaNAmSY1q2mHEpchsMzlKK+POCPw9Ic27aT263FRi pSw4hs4YDZqf3LoF9MC/l1V1pAYMOUSLzzO1H6j+uc6UJiMZTFStbS1AL Q==; X-CSE-ConnectionGUID: ogkJhTNkQd6e8htZnZPbmg== X-CSE-MsgGUID: UEuiXXqBSqCCr6SEJ7OwXQ== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254463" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254463" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:00 -0700 X-CSE-ConnectionGUID: Y7LmAJOSQYWVnMRl+LGvvw== X-CSE-MsgGUID: FD6aC6ifTD6sHu3HIhWdbg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354483" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:00 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 06/15] x86/efi: Disable LASS while mapping the EFI runtime services Date: Mon, 6 Oct 2025 23:51:10 -0700 Message-ID: <20251007065119.148605-7-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexander Shishkin While mapping EFI runtime services, set_virtual_address_map() is called at its lower mapping, which LASS prohibits. Wrapping the EFI call with lass_stac()/clac() is not enough, because the AC flag only gates data accesses, and not instruction fetches. Use the big hammer and toggle the CR4.LASS bit to make this work. Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Signed-off-by: Sohil Mehta --- v10: - Reword code comments --- arch/x86/platform/efi/efi.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 463b784499a8..cc00a7e6599e 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -786,8 +786,8 @@ static void __init __efi_enter_virtual_mode(void) { int count =3D 0, pg_shift =3D 0; void *new_memmap =3D NULL; + unsigned long pa, lass; efi_status_t status; - unsigned long pa; =20 if (efi_alloc_page_tables()) { pr_err("Failed to allocate EFI page tables\n"); @@ -825,11 +825,23 @@ static void __init __efi_enter_virtual_mode(void) =20 efi_sync_low_kernel_mappings(); =20 + /* + * LASS complains because set_virtual_address_map() is located + * at a lower address. To pause enforcement, flipping RFLAGS.AC + * is not sufficient here, as it only permits data access and + * not instruction fetch. Disable the entire LASS mechanism. + */ + lass =3D cr4_read_shadow() & X86_CR4_LASS; + cr4_clear_bits(lass); + status =3D efi_set_virtual_address_map(efi.memmap.desc_size * count, efi.memmap.desc_size, efi.memmap.desc_version, (efi_memory_desc_t *)pa, efi_systab_phys); + + cr4_set_bits(lass); + if (status !=3D EFI_SUCCESS) { pr_err("Unable to switch EFI into virtual mode (status=3D%lx)!\n", status); --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 6356E23BD17; Tue, 7 Oct 2025 06:54:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820044; cv=none; b=f2sljcQjm/l7sleUKK1CjRtuHks8tyqsM0qijbU0JC1Jh80SVtaqRA1YvKhw8R0Eie+qkWstSNJQeB/TMjeqH66VKFkniBKYh3n9knTPzA2XM7mrJSwaR/9F/nrFJRv5g+K8BnqMfZ7sGXOXdxI7h1FmqO5UEoNEJJtqDb23fDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820044; c=relaxed/simple; bh=hIq1Gw3KtkiqpD02POfZXf3xLAd/wm5guqT+PTGj6r0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oC9KKKJ8ot/HP5KUV5PccHHvb9/Mv/Tu4mzOt7ycP4aHa4ejJGBgnopIMGe2Ac5zyV3mJoGCLAb3vYVB0slvgCLRsKYG+wnTZgyjEoeIfq1AwaslIS2d40OSJP6ddcaXtPAjHB8kBlJkyaFu9ZVkJ1+T/TP4QhsC/rx2BATHZCw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=mhpkkTgL; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="mhpkkTgL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820042; x=1791356042; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=hIq1Gw3KtkiqpD02POfZXf3xLAd/wm5guqT+PTGj6r0=; b=mhpkkTgL4+AABfPbbEcgRlSWPsG+s9pAqtkFhJqRf6/u6ZB0Y5XLSa5L zoW1wAoYynGvrmmwqV2EeEBCBIrY8uAzDb03B0zXVdNMYWpL8cYZYFSOk 6/MxbYs1nRzOtN5Dp7RNaicuoqHdBpAAdKBu49B4r9qQoEFxCzSSyyldI OcxE0wPijm9gPL0WoJvPyC+9PgTxUqMg+WzcmRCxrrMrigPbY3rfhH1c8 5V2GlavoeN/9Hk3TO5EX2KJeGzwDhwKVgYjB1u1BAiMQhA0iFmPLUB6AH w8Q1QzJMnP6KVuDGk5B5YV1FN7dRVrlAfDsHuGt06Kx38QFSL69UvhtB0 w==; X-CSE-ConnectionGUID: uTOOz0QvRjWgEbYEsmFpMA== X-CSE-MsgGUID: 7sUzfKCJTb+5byTcJu2gbQ== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254478" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254478" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:01 -0700 X-CSE-ConnectionGUID: tuhU5btZS7y2fiJuYV/SCg== X-CSE-MsgGUID: ZzewQD2lTIOQBCHmq4O71w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354487" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:00 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 07/15] x86/kexec: Disable LASS during relocate kernel Date: Mon, 6 Oct 2025 23:51:11 -0700 Message-ID: <20251007065119.148605-8-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Relocate kernel uses identity mapping to copy the new kernel which leads to an LASS violation. To avoid issues, disable LASS after the original CR4 value has been saved but before jumping to the identity mapped page. Signed-off-by: Sohil Mehta --- v10: - New patch to fix an issue detected during internal testing. --- arch/x86/kernel/relocate_kernel_64.S | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocat= e_kernel_64.S index 11e20bb13aca..4ffba68dc57b 100644 --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -95,9 +95,12 @@ SYM_CODE_START_NOALIGN(relocate_kernel) /* Leave CR4 in %r13 to enable the right paging mode later. */ movq %cr4, %r13 =20 - /* Disable global pages immediately to ensure this mapping is RWX */ + /* + * Disable global pages immediately to ensure this mapping is RWX. + * Disable LASS before jumping to the identity mapped page. + */ movq %r13, %r12 - andq $~(X86_CR4_PGE), %r12 + andq $~(X86_CR4_PGE | X86_CR4_LASS), %r12 movq %r12, %cr4 =20 /* Save %rsp and CRs. */ --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 2E84123D291; Tue, 7 Oct 2025 06:54:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820045; cv=none; b=c1F8dpkuNjOIen8REvD6Dye0CfhdqWhILW7N+YiFCaIjhajHmRmPMp29yGlPa6TjMMqXW3RVfrasv4RVXP3vmTl5AO35gvPnTxiPdJNX17pkVi9vVFRrqgibnvbuFedFgR2qqwR7LLH3KWIkUmeO/6RgFWVyKosfHYrmn8kBCWs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820045; c=relaxed/simple; bh=L1412De9Yvq24CgH8jzCj11Nqy+A7G5FnvSZgrqJw+s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OUIJnCJdLgynX/sOyRllLAHxurRWWBrSIG9mLuPcA3GE6qOROQ9pxFZHlpOrHHIhsCptRBVjpGUsrowsmeUWlCByRbarfZ4eXbr0+KJhuRKcm4Qw3KC/eli5j/mOZ5d3LXObMN8onTPTRhSxgtODc7JSCAlu2xOcuDRF+VALUAY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=cz0mPSeu; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="cz0mPSeu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820043; x=1791356043; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=L1412De9Yvq24CgH8jzCj11Nqy+A7G5FnvSZgrqJw+s=; b=cz0mPSeu1YfwdCdQzNrQ4P4GyrbWp/1l++zADpH3BiNmGBisxzKkq34x HxcpqsmeOeK7eItx9R+ibTcsNqifX+kr/2SSkhbfcYqzJhin4abls4ncH QEiMRVrUKhDOoyppiXntvjlA84eD+1vjqMwaa3AKPA4TSTP57PUJ70d6X OVAT9UghFnUzxP0bv11VzboIZhL2Zs5CKCQ/rkfXhvsyuBOG6ajBjPHLX 4VDFUWy1Mtj1ufvBFmVqD/cc3x+tTq6EOm/+l5P6NS15WxgXzBRxYYTy/ dUnncrcApsSZjuvoWr4mg/N07GrpEiYN+qtoGkj5OirsPMNCwRGJo/PGC w==; X-CSE-ConnectionGUID: ojAaAOM5Qa+KTIxg7qM30w== X-CSE-MsgGUID: WeAS9pTNTfiS184pVJXLUg== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254492" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254492" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:01 -0700 X-CSE-ConnectionGUID: ZwlmAu9rTFaY9fu19UBIhg== X-CSE-MsgGUID: Y3nw+8ShSqenP1s8GIBW5Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354491" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:01 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 08/15] x86/vsyscall: Reorganize the page fault emulation code Date: Mon, 6 Oct 2025 23:51:12 -0700 Message-ID: <20251007065119.148605-9-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Separate out the actual vsyscall emulation from the #PF specific handling in preparation for the upcoming #GP emulation. No functional change intended. Signed-off-by: Sohil Mehta Acked-by: Dave Hansen --- v10: - Modify the code flow slightly to make it easier to follow. --- arch/x86/entry/vsyscall/vsyscall_64.c | 63 ++++++++++++++------------- arch/x86/include/asm/vsyscall.h | 7 ++- arch/x86/mm/fault.c | 2 +- 3 files changed, 36 insertions(+), 36 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index 6e6c0a740837..4c3f49bf39e6 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -112,43 +112,13 @@ static bool write_ok_or_segv(unsigned long ptr, size_= t size) } } =20 -bool emulate_vsyscall(unsigned long error_code, - struct pt_regs *regs, unsigned long address) +static bool __emulate_vsyscall(struct pt_regs *regs, unsigned long address) { unsigned long caller; int vsyscall_nr, syscall_nr, tmp; long ret; unsigned long orig_dx; =20 - /* Write faults or kernel-privilege faults never get fixed up. */ - if ((error_code & (X86_PF_WRITE | X86_PF_USER)) !=3D X86_PF_USER) - return false; - - /* - * Assume that faults at regs->ip are because of an - * instruction fetch. Return early and avoid - * emulation for faults during data accesses: - */ - if (address !=3D regs->ip) { - /* Failed vsyscall read */ - if (vsyscall_mode =3D=3D EMULATE) - return false; - - /* - * User code tried and failed to read the vsyscall page. - */ - warn_bad_vsyscall(KERN_INFO, regs, "vsyscall read attempt denied -- look= up the vsyscall kernel parameter if you need a workaround"); - return false; - } - - /* - * X86_PF_INSTR is only set when NX is supported. When - * available, use it to double-check that the emulation code - * is only being used for instruction fetches: - */ - if (cpu_feature_enabled(X86_FEATURE_NX)) - WARN_ON_ONCE(!(error_code & X86_PF_INSTR)); - /* * No point in checking CS -- the only way to get here is a user mode * trap to a high address, which means that we're in 64-bit user code. @@ -281,6 +251,37 @@ bool emulate_vsyscall(unsigned long error_code, return true; } =20 +bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, + unsigned long address) +{ + /* Write faults or kernel-privilege faults never get fixed up. */ + if ((error_code & (X86_PF_WRITE | X86_PF_USER)) !=3D X86_PF_USER) + return false; + + /* + * Assume that faults at regs->ip are because of an instruction + * fetch. Return early and avoid emulation for faults during + * data accesses: + */ + if (address !=3D regs->ip) { + /* User code tried and failed to read the vsyscall page. */ + if (vsyscall_mode !=3D EMULATE) + warn_bad_vsyscall(KERN_INFO, regs, "vsyscall read attempt denied -- loo= k up the vsyscall kernel parameter if you need a workaround"); + + return false; + } + + /* + * X86_PF_INSTR is only set when NX is supported. When + * available, use it to double-check that the emulation code + * is only being used for instruction fetches: + */ + if (cpu_feature_enabled(X86_FEATURE_NX)) + WARN_ON_ONCE(!(error_code & X86_PF_INSTR)); + + return __emulate_vsyscall(regs, address); +} + /* * A pseudo VMA to allow ptrace access for the vsyscall page. This only * covers the 64bit vsyscall page now. 32bit has a real VMA now and does diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscal= l.h index 472f0263dbc6..f34902364972 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -14,12 +14,11 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root); * Called on instruction fetch fault in vsyscall page. * Returns true if handled. */ -extern bool emulate_vsyscall(unsigned long error_code, - struct pt_regs *regs, unsigned long address); +bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, u= nsigned long address); #else static inline void map_vsyscall(void) {} -static inline bool emulate_vsyscall(unsigned long error_code, - struct pt_regs *regs, unsigned long address) +static inline bool emulate_vsyscall_pf(unsigned long error_code, + struct pt_regs *regs, unsigned long address) { return false; } diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 998bd807fc7b..fbcc2da75fd6 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1316,7 +1316,7 @@ void do_user_addr_fault(struct pt_regs *regs, * to consider the PF_PK bit. */ if (is_vsyscall_vaddr(address)) { - if (emulate_vsyscall(error_code, regs, address)) + if (emulate_vsyscall_pf(error_code, regs, address)) return; } #endif --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 6DEAD23E320; Tue, 7 Oct 2025 06:54:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820045; cv=none; b=N2R8/iGcJ+vqcfaeWonVxCwBo1hV96rDMWVMTflUik57Y7gjkMz8wyStJkCO8vOh6cxvWtVNZ9MuX2E4FA4903kebA8CDiSAEfe3lW4I732FU2ykz/PlYTKxFoaV6Ff4dH66Latx5yKLL7AM+KD+iId2JE6mGMZykq7I6MhcP+U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820045; c=relaxed/simple; bh=fToSm3F404n5oMzJvpVQXG31dFxiu2syuP8/cuc42Tk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MDsgSOZAMjhpYY0mY1mDlU9dMxdqO8OeUQb1k60Mc6Z48140RlyGXU2hN2EpdwYlJixHMTZKC4s2KMnpPj94xJdYMYTAOqRVKPupG68K1UpEPPIOnDfRdW7uQC/Qa6c7PMWEgcByHifvgvx6WfB6qEBBCTsnGGer6y2/mvEw570= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MFHStz/e; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MFHStz/e" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820043; x=1791356043; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=fToSm3F404n5oMzJvpVQXG31dFxiu2syuP8/cuc42Tk=; b=MFHStz/ejIzeIHq9CAQCNy1IrDlT4/QAsyWhDMNVX4/F19LvPnyqoEko hTpt44hPEaYEPG4Tr9SQf1yVyWtOiJWpVOsdf2+JwGQyQPb18HfVcVVcs AlR3waqQFIDvBPDNlCHIYv+zvG15lNEz/RkmE0dPN8P6X0iJy1xH50/fm 36teefBFP0vz+Mw89qola0TZux5sO/BB8KDTC/uVKwNeSt3n1GDyJe6RW 8wiPg2pSzQ0WKXQRmT/aecU3w5iD+WF9g2sjAx6w4V2KTSOrL6qxZFvps kxs+UgT3UO/jUYcWZJzf5aoudM/j2UhOafkGqsKSw+icxEOQoGYtKcvpB A==; X-CSE-ConnectionGUID: cbXXOxX4SJCN6810asMNkw== X-CSE-MsgGUID: 0j0dXeKBTQCCqlZUmG28iQ== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254507" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254507" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:02 -0700 X-CSE-ConnectionGUID: /07oEOVeQky7thGWhzSgAw== X-CSE-MsgGUID: W9a/EJe9TPavxP4/usmwrg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354495" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:02 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 09/15] x86/traps: Consolidate user fixups in exc_general_protection() Date: Mon, 6 Oct 2025 23:51:13 -0700 Message-ID: <20251007065119.148605-10-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Move the UMIP exception fixup along with the other user mode fixups, that is, under the common "if (user_mode(regs))" condition where the rest of the fixups reside. No functional change intended. Suggested-by: Dave Hansen Signed-off-by: Sohil Mehta Acked-by: Dave Hansen --- v10: - No change. --- arch/x86/kernel/traps.c | 8 +++----- arch/x86/kernel/umip.c | 3 +++ 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 36354b470590..25b45193eb19 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -800,11 +800,6 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) =20 cond_local_irq_enable(regs); =20 - if (static_cpu_has(X86_FEATURE_UMIP)) { - if (user_mode(regs) && fixup_umip_exception(regs)) - goto exit; - } - if (v8086_mode(regs)) { local_irq_enable(); handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code); @@ -819,6 +814,9 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) if (fixup_vdso_exception(regs, X86_TRAP_GP, error_code, 0)) goto exit; =20 + if (fixup_umip_exception(regs)) + goto exit; + gp_user_force_sig_segv(regs, X86_TRAP_GP, error_code, desc); goto exit; } diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c index d432f3824f0c..3ce99cbcf187 100644 --- a/arch/x86/kernel/umip.c +++ b/arch/x86/kernel/umip.c @@ -354,6 +354,9 @@ bool fixup_umip_exception(struct pt_regs *regs) void __user *uaddr; struct insn insn; =20 + if (!cpu_feature_enabled(X86_FEATURE_UMIP)) + return false; + if (!regs) return false; =20 --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 4545A244670; Tue, 7 Oct 2025 06:54:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820046; cv=none; b=hQIsBbBKyE6uaJf5FWFcqINjjVn1XlXBBl+CzP4otbmrAXQg+YYVFMQ/ebUY0sdk4M9x7L1uDBXQ5XuudoogBsELDXgsHZCCJg+AZ9EEed1i4luiMVl0Tonau6Ak+renh5iwVLpZZxHLCc/U/eLMnYoVwDeJA5pz6IzVB0X9kYE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820046; c=relaxed/simple; bh=Q7agOSCAERHWB5so+wxbqMf9sjQ0R+iLN74s/s56CAk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rl7l/enI1Z9YZCKTeT72HFnbq8xPnz0GhUs5initlOqktRPXDUTDv+hub6/HACf8G5nZebuLjbEsk+PJ7ihYAUIMsP7hPICuIAOz1HGisfIx8bxwFVlRodlv7IAeCESuih8lorV8j8M0yanh6LPjphdlPyicWx786lXJZZBVu78= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=gl9Dn709; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="gl9Dn709" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820044; x=1791356044; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Q7agOSCAERHWB5so+wxbqMf9sjQ0R+iLN74s/s56CAk=; b=gl9Dn709b5P/MaWjrWewxXDM6wJaSW3jtu5YOmjV00DqL2ZBkD9vcUZL No3n8d3P5At/uDlVl2fkof4/VCVGhC8VHGD9eWvcyHzAhmjOfIbWSVAU1 BJydH876yip6cA/RjmnbmnluzQbdDWZzg6dtWZqtyjBzByanzsV8od6th EvYhb5zJC0fDRJWAl3/Bi+YnOPdw9GlQUuTjA9kqspiFwUhCn829DL1wA OfqqhfvN4yI6geefayf7Q1Jtyk1xfqoVqHihJXVy/WhjW3KkuVU6LhI0/ bkIOMi7YUwRkZ2nUimeOPbeQ9EY6ruhd8JhEmat7vNSFNggmdhrP5lRBm Q==; X-CSE-ConnectionGUID: +BbQqzGdQ4+kt+9TEmH2Tw== X-CSE-MsgGUID: qwyayd3oTjKgshbzMYsu7A== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254521" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254521" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:03 -0700 X-CSE-ConnectionGUID: yLXKUA1+S5qtfzLq6a5LLw== X-CSE-MsgGUID: DH8lp9h+RfyypJg5xm6YTQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354498" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:02 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 10/15] x86/vsyscall: Add vsyscall emulation for #GP Date: Mon, 6 Oct 2025 23:51:14 -0700 Message-ID: <20251007065119.148605-11-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The legacy vsyscall page is mapped at a fixed address in the kernel address range 0xffffffffff600000-0xffffffffff601000. Prior to LASS, a vsyscall page access from userspace would always generate a #PF. The kernel emulates the execute (XONLY) accesses in the #PF handler and returns the appropriate values to userspace. With LASS, these accesses are intercepted before the paging structures are traversed triggering a #GP instead of a #PF. However, the #GP doesn't provide much information in terms of the error code. Emulate the vsyscall access without going through complex instruction decoding. Use the faulting RIP which is preserved in the user registers to determine if the #GP was triggered due to a vsyscall access. Signed-off-by: Sohil Mehta --- v10: - No change. --- arch/x86/entry/vsyscall/vsyscall_64.c | 14 +++++++++++++- arch/x86/include/asm/vsyscall.h | 6 ++++++ arch/x86/kernel/traps.c | 4 ++++ 3 files changed, 23 insertions(+), 1 deletion(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index 4c3f49bf39e6..ff319d7e778c 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -23,7 +23,7 @@ * soon be no new userspace code that will ever use a vsyscall. * * The code in this file emulates vsyscalls when notified of a page - * fault to a vsyscall address. + * fault or a general protection fault to a vsyscall address. */ =20 #include @@ -282,6 +282,18 @@ bool emulate_vsyscall_pf(unsigned long error_code, str= uct pt_regs *regs, return __emulate_vsyscall(regs, address); } =20 +bool emulate_vsyscall_gp(struct pt_regs *regs) +{ + if (!cpu_feature_enabled(X86_FEATURE_LASS)) + return false; + + /* Emulate only if the RIP points to the vsyscall address */ + if (!is_vsyscall_vaddr(regs->ip)) + return false; + + return __emulate_vsyscall(regs, regs->ip); +} + /* * A pseudo VMA to allow ptrace access for the vsyscall page. This only * covers the 64bit vsyscall page now. 32bit has a real VMA now and does diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscal= l.h index f34902364972..538053b1656a 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -15,6 +15,7 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root); * Returns true if handled. */ bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, u= nsigned long address); +bool emulate_vsyscall_gp(struct pt_regs *regs); #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall_pf(unsigned long error_code, @@ -22,6 +23,11 @@ static inline bool emulate_vsyscall_pf(unsigned long err= or_code, { return false; } + +static inline bool emulate_vsyscall_gp(struct pt_regs *regs) +{ + return false; +} #endif =20 /* diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 25b45193eb19..59bfbdf0a1a0 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -69,6 +69,7 @@ #include #include #include +#include =20 #ifdef CONFIG_X86_64 #include @@ -817,6 +818,9 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) if (fixup_umip_exception(regs)) goto exit; =20 + if (emulate_vsyscall_gp(regs)) + goto exit; + gp_user_force_sig_segv(regs, X86_TRAP_GP, error_code, desc); goto exit; } --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 4C1FB247283; Tue, 7 Oct 2025 06:54:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820047; cv=none; b=JVysrHZ03ZYzPoX+jsEOW//2HqLMIYqA5xhQevgtPLKVhOkom0UlhKLjcikEHEd0UK9lsAic44wAWnJx5fT4BQqRoQNgOdU2lGpF+t7Kp5YTUMsSpCRdgwG1fmV16foZgFmW4Fpp0Uis8IW96FRM1/KWkjZtT2F6wV+CLr3oG5U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820047; c=relaxed/simple; bh=AO7ttp/5/5QVnC/MxKsk0OxVOwOWTlktVqE63h4+7Xg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YwXkS7Aohq+3QYRteIwsHqkm9ttNKuwSLptD7oibINa2h9qlJWnLRqU4ncxvug9j/W+fRIu6FWEoMc8xfBs0bB6KJSm6XQrgVoHn8RsK4zJUZHiyDvO0bF6Z0xA+/bD9ouk0s5PSsfybVWuhZcp8S6+muKCgYslsyDnWCcixT1M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=AhcRoHsK; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="AhcRoHsK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820045; x=1791356045; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=AO7ttp/5/5QVnC/MxKsk0OxVOwOWTlktVqE63h4+7Xg=; b=AhcRoHsKJ3yfGmPx2M7JnPn/ddkUbwKAXqd35TTG7zaVB8z1tRL/5Zsn FblCOxVYA2wJi45OzxylNpy02mh37/uEeqmGs8Qi0ZymJHM6DXPYQcRcH SfK2Zu5rBaZOJv8gjjAq07SCpTJ9iy/YdY46/Fir/NRsDicLlhMxb16Aw K+y2NpYYJ1HvqdnOB2HHv9p5tfOsbgMHW24g8uCZH2Q7XArfhm/mE5cyc ECgN2y8Dgg07WWuyrTlaKr19hTwIAT1f0DrVzhNUXsAFPbuzFeCafFKTx oyp6vabTppVQcYjLBivb0ZL2axbTBxXXPtnweJQSRtUc6wQv2mH0J2rwH w==; X-CSE-ConnectionGUID: xwZL4OcPQE2CFQre5ntEEw== X-CSE-MsgGUID: L2ehowAZQWqk0r/NTvEgTw== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254536" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254536" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:04 -0700 X-CSE-ConnectionGUID: x+zKuobOROqk+e2cR02x0w== X-CSE-MsgGUID: Ch4nlKf7TMCIH2lUBzZYiQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354505" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:03 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 11/15] x86/vsyscall: Disable LASS if vsyscall mode is set to EMULATE Date: Mon, 6 Oct 2025 23:51:15 -0700 Message-ID: <20251007065119.148605-12-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The EMULATE mode of vsyscall maps the vsyscall page with a high kernel address directly into user address space. Reading the vsyscall page in EMULATE mode would cause LASS to trigger a #GP. Fixing the LASS violation in EMULATE mode would require complex instruction decoding because the resulting #GP does not include any useful error information, and the vsyscall address is not readily available in the RIP. The EMULATE mode has been deprecated since 2022 and can only be enabled using the command line parameter vsyscall=3Demulate. See commit bf00745e7791 ("x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE") for details. At this point, no one is expected to be using this insecure mode. The rare usages that need it obviously do not care about security. Disable LASS when EMULATE mode is requested to avoid breaking legacy user software. Also, update the vsyscall documentation to reflect this. LASS will only be supported if vsyscall mode is set to XONLY (default) or NONE. Signed-off-by: Sohil Mehta Reviewed-by: Rick Edgecombe --- v10: - No significant change. Minor changes to code formatting. Eventually, we want to get rid of the EMULATE mode altogether. Linus and AndyL seem to be okay with such a change. However, those changes are beyond the scope of this series. --- Documentation/admin-guide/kernel-parameters.txt | 4 +++- arch/x86/entry/vsyscall/vsyscall_64.c | 6 ++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio= n/admin-guide/kernel-parameters.txt index 3edc5ce0e2a3..29a2ee9e1001 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -8079,7 +8079,9 @@ =20 emulate Vsyscalls turn into traps and are emulated reasonably safely. The vsyscall page is - readable. + readable. This disables the Linear + Address Space Separation (LASS) security + feature and makes the system less secure. =20 xonly [default] Vsyscalls turn into traps and are emulated reasonably safely. The vsyscall diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index ff319d7e778c..57498609b1f0 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -63,6 +63,12 @@ static int __init vsyscall_setup(char *str) else return -EINVAL; =20 + if (cpu_feature_enabled(X86_FEATURE_LASS) && vsyscall_mode =3D=3D EMULAT= E) { + cr4_clear_bits(X86_CR4_LASS); + setup_clear_cpu_cap(X86_FEATURE_LASS); + pr_warn_once("x86/cpu: Disabling LASS due to vsyscall=3Demulate\n"); + } + return 0; } =20 --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 7607C248891; Tue, 7 Oct 2025 06:54:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820047; cv=none; b=lTpf7dkVCVVVcdKG1OMwZXlDtqjfTu/TYzm37blJ0t5cEWxGibp6QNkTOf/U4KPz48MutmWDH3ZFkpRgOtwW17Hnl2IhpWcf5mQPlebRcqIVCC62wjzCG25ssr9Te8Mxxf3ng8DQFSdl3EObWaX1DNRmZ5Kba6+9U+ZgZg2lPgI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820047; c=relaxed/simple; bh=v/AnKYeaBYwv41cfbhsnq6Xu2el1+0Obs9DJw12Tbk8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sU4KRG8yNp+fJX0NKg3ML4mK0Atd6WCaL/2/eZs/XsyNghX9YgQ3zpHItSLqFXmGOXA3ICoLokiPdsEYLFjOj375S+alENbNjpzem/ueh7cLoiaHnhewcQEMB0qQX48zYvHhRAKqjiG5t3O+VHKFR4bnLcG5gd3jIv8qmiPzniM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=C2HIlisy; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="C2HIlisy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820045; x=1791356045; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=v/AnKYeaBYwv41cfbhsnq6Xu2el1+0Obs9DJw12Tbk8=; b=C2HIlisyJCZrzXDq2V7yKg+KhF4T5qctl7cvDW3vSRfXw5xOtOyZK48f ipqMF+o3sQeV5rkmiceB4H3T1+Ljtx5caPIpDsl/nfSPxKTyUutOtFvLu jUVViTL+ugEAIqGMOYDVA1iu7X1qn139cGZv32kYofXjne/Kjv1rTE/dR xSSDiNjcOIfxklTdkcvKq4b/Bm694TPk9pEFQjReteDvzgBDEoAFhsWO6 tV+jY1GzICxtpTI/g3Vixf7XHDpEJ0TqMbv1VE9HsYJZgRXhB2kMDGZtW w3r5byFtChezA7ydvsnchZ6rZvvE2V21a5v9bHsbjGzVrecLwsEPIwXMK Q==; X-CSE-ConnectionGUID: tx64B/g8RXCf3vOSGOr8NQ== X-CSE-MsgGUID: eXYu5cC8SH2o6L4uLe+MZg== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254550" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254550" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:04 -0700 X-CSE-ConnectionGUID: 3KaV5gyFQ0qS21LHPv6qNg== X-CSE-MsgGUID: YTkL3ObtQ2qdJffQ0doyjA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354508" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:04 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 12/15] x86/traps: Communicate a LASS violation in #GP message Date: Mon, 6 Oct 2025 23:51:16 -0700 Message-ID: <20251007065119.148605-13-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexander Shishkin A LASS violation typically results in a #GP. Provide a more helpful message for a #GP when a kernel-side LASS violation is detected. Currently, a kernel NULL pointer dereference triggers a #PF, which prints a helpful message. Because LASS enforcement is pre-paging, accesses to the first page frame would now be reported as a #GP, with an LASS violation hint. Add a special case to print a friendly message specifically for kernel NULL pointer dereferences. Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Signed-off-by: Sohil Mehta --- v10: - Minor improvement to code comments and hints. --- arch/x86/kernel/traps.c | 45 ++++++++++++++++++++++++++++++----------- 1 file changed, 33 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 59bfbdf0a1a0..a5d10f7ae038 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -636,13 +636,23 @@ DEFINE_IDTENTRY(exc_bounds) enum kernel_gp_hint { GP_NO_HINT, GP_NON_CANONICAL, - GP_CANONICAL + GP_CANONICAL, + GP_LASS_VIOLATION, + GP_NULL_POINTER, +}; + +static const char * const kernel_gp_hint_help[] =3D { + [GP_NON_CANONICAL] =3D "probably for non-canonical address", + [GP_CANONICAL] =3D "maybe for address", + [GP_LASS_VIOLATION] =3D "probably LASS violation for address", + [GP_NULL_POINTER] =3D "kernel NULL pointer dereference", }; =20 /* * When an uncaught #GP occurs, try to determine the memory address access= ed by * the instruction and return that address to the caller. Also, try to fig= ure - * out whether any part of the access to that address was non-canonical. + * out whether any part of the access to that address was non-canonical or + * across privilege levels. */ static enum kernel_gp_hint get_kernel_gp_address(struct pt_regs *regs, unsigned long *addr) @@ -664,14 +674,27 @@ static enum kernel_gp_hint get_kernel_gp_address(stru= ct pt_regs *regs, return GP_NO_HINT; =20 #ifdef CONFIG_X86_64 - /* - * Check that: - * - the operand is not in the kernel half - * - the last byte of the operand is not in the user canonical half - */ - if (*addr < ~__VIRTUAL_MASK && - *addr + insn.opnd_bytes - 1 > __VIRTUAL_MASK) + /* Operand is in the kernel half */ + if (*addr >=3D ~__VIRTUAL_MASK) + return GP_CANONICAL; + + /* The last byte of the operand is not in the user canonical half */ + if (*addr + insn.opnd_bytes - 1 > __VIRTUAL_MASK) return GP_NON_CANONICAL; + + /* + * If LASS is active, a NULL pointer dereference generates a #GP + * instead of a #PF. + */ + if (*addr < PAGE_SIZE) + return GP_NULL_POINTER; + + /* + * Assume that LASS caused the exception, because the address is + * canonical and in the user half. + */ + if (cpu_feature_enabled(X86_FEATURE_LASS)) + return GP_LASS_VIOLATION; #endif =20 return GP_CANONICAL; @@ -835,9 +858,7 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) =20 if (hint !=3D GP_NO_HINT) snprintf(desc, sizeof(desc), GPFSTR ", %s 0x%lx", - (hint =3D=3D GP_NON_CANONICAL) ? "probably for non-canonical address" - : "maybe for address", - gp_addr); + kernel_gp_hint_help[hint], gp_addr); =20 /* * KASAN is interested only in the non-canonical case, clear it --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 58525254849; Tue, 7 Oct 2025 06:54:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820048; cv=none; b=njAwHsByuIUBWDy187v787aj2TnJ4UTtXfym0018AMAPFYMPQOvfYDG3CWHBiU0A36NLlp8Z5YWUbr8PgwLGwEYkSRRfTl8X1VFWYXTORUnqaVxCBdTIVkZFeuefpluggzGnC3ptMLD9DWI9LAeLPxmsg5BJ4PpTc7WMICQAv2k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820048; c=relaxed/simple; bh=lVd0dGclYG6A0JMoKxaE+Hy/0Xq4JKmJR9usTLj67Vs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iECc9AGL1Wunt1Z5RjIdy511ddmpoTX8X80ynG0r+s5KgK3RopZdZJorBPoFglDDPPMLCJzru/OjdqMy2jyEoGl3gYaY5wqjfM5PwryzNrfT8nHgPAc6goEIHWOe+TwJf7nmJI/mYlSaF04w2GQ3sHu5e4C3CBQ1dewvv6CdqY4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=k5e4UpV7; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="k5e4UpV7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820046; x=1791356046; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=lVd0dGclYG6A0JMoKxaE+Hy/0Xq4JKmJR9usTLj67Vs=; b=k5e4UpV7CsiWV+T02m3ha1vkEseu8MZY0ny4uglDJLYXXY9D/M+fypBV CD/7/Tg5RvkFYuNg8zPj74Ff3kMRC2nfyjhNIOcvMIv1vC5yhcbc+2EOO A3nZ+SmCCiIlGQxCECf8cDTe18atvlNhahBB7sqrsv26iTBQPoH8/UZEl hlAa9WMc0lv4YrcW/9ILb5q/zVJ0koNWp/G486Qi26/JAggV/z8+JY9Cl PRbxmZpkvAn8gZVXWBACdV7XtR/V3L32oBzywWKo6D3fGi3YTcrjl+rRY Rqi8MRkZNMKAsQ7eBB1DsfPH1LA1RVKB50XgHQd5D5ClMyk+x/A6CXZFH g==; X-CSE-ConnectionGUID: B6ScM5yfRwqRGwHY/dA+YA== X-CSE-MsgGUID: CnAYBM/jRymj7X/e4fCvHQ== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254564" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254564" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:05 -0700 X-CSE-ConnectionGUID: +JZNyZGFSHqDN4Hc4BrdOw== X-CSE-MsgGUID: nbpydRRJQwOukf8imMUlcA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354513" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:05 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 13/15] x86/traps: Generalize #GP address decode and hint code Date: Mon, 6 Oct 2025 23:51:17 -0700 Message-ID: <20251007065119.148605-14-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Kirill A. Shutemov" In most cases, an access causing a LASS violation results in a #GP, for stack accesses (those due to stack-oriented instructions, as well as accesses that implicitly or explicitly use the SS segment register), a stack segment fault (#SS) is generated. Handlers for #GP and #SS will soon share code to decode the exception address and retrieve the exception hint string. Rename the helper function as well as the enum and array names to reflect that they are no longer specific to #GP. No functional change intended. Signed-off-by: Kirill A. Shutemov Signed-off-by: Sohil Mehta Reviewed-by: Rick Edgecombe --- v10: - No change. --- arch/x86/kernel/dumpstack.c | 6 ++-- arch/x86/kernel/traps.c | 60 ++++++++++++++++++------------------- 2 files changed, 33 insertions(+), 33 deletions(-) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c index 71ee20102a8a..e0f85214e92f 100644 --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -441,14 +441,14 @@ void die(const char *str, struct pt_regs *regs, long = err) oops_end(flags, regs, sig); } =20 -void die_addr(const char *str, struct pt_regs *regs, long err, long gp_add= r) +void die_addr(const char *str, struct pt_regs *regs, long err, long addr) { unsigned long flags =3D oops_begin(); int sig =3D SIGSEGV; =20 __die_header(str, regs, err); - if (gp_addr) - kasan_non_canonical_hook(gp_addr); + if (addr) + kasan_non_canonical_hook(addr); if (__die_body(str, regs, err)) sig =3D 0; oops_end(flags, regs, sig); diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index a5d10f7ae038..3ee8a36a4e6a 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -633,29 +633,29 @@ DEFINE_IDTENTRY(exc_bounds) cond_local_irq_disable(regs); } =20 -enum kernel_gp_hint { - GP_NO_HINT, - GP_NON_CANONICAL, - GP_CANONICAL, - GP_LASS_VIOLATION, - GP_NULL_POINTER, +enum kernel_exc_hint { + EXC_NO_HINT, + EXC_NON_CANONICAL, + EXC_CANONICAL, + EXC_LASS_VIOLATION, + EXC_NULL_POINTER, }; =20 -static const char * const kernel_gp_hint_help[] =3D { - [GP_NON_CANONICAL] =3D "probably for non-canonical address", - [GP_CANONICAL] =3D "maybe for address", - [GP_LASS_VIOLATION] =3D "probably LASS violation for address", - [GP_NULL_POINTER] =3D "kernel NULL pointer dereference", +static const char * const kernel_exc_hint_help[] =3D { + [EXC_NON_CANONICAL] =3D "probably for non-canonical address", + [EXC_CANONICAL] =3D "maybe for address", + [EXC_LASS_VIOLATION] =3D "probably LASS violation for address", + [EXC_NULL_POINTER] =3D "kernel NULL pointer dereference", }; =20 /* - * When an uncaught #GP occurs, try to determine the memory address access= ed by - * the instruction and return that address to the caller. Also, try to fig= ure - * out whether any part of the access to that address was non-canonical or - * across privilege levels. + * When an uncaught #GP/#SS occurs, try to determine the memory address + * accessed by the instruction and return that address to the caller. + * Also, try to figure out whether any part of the access to that + * address was non-canonical or across privilege levels. */ -static enum kernel_gp_hint get_kernel_gp_address(struct pt_regs *regs, - unsigned long *addr) +static enum kernel_exc_hint get_kernel_exc_address(struct pt_regs *regs, + unsigned long *addr) { u8 insn_buf[MAX_INSN_SIZE]; struct insn insn; @@ -663,41 +663,41 @@ static enum kernel_gp_hint get_kernel_gp_address(stru= ct pt_regs *regs, =20 if (copy_from_kernel_nofault(insn_buf, (void *)regs->ip, MAX_INSN_SIZE)) - return GP_NO_HINT; + return EXC_NO_HINT; =20 ret =3D insn_decode_kernel(&insn, insn_buf); if (ret < 0) - return GP_NO_HINT; + return EXC_NO_HINT; =20 *addr =3D (unsigned long)insn_get_addr_ref(&insn, regs); if (*addr =3D=3D -1UL) - return GP_NO_HINT; + return EXC_NO_HINT; =20 #ifdef CONFIG_X86_64 /* Operand is in the kernel half */ if (*addr >=3D ~__VIRTUAL_MASK) - return GP_CANONICAL; + return EXC_CANONICAL; =20 /* The last byte of the operand is not in the user canonical half */ if (*addr + insn.opnd_bytes - 1 > __VIRTUAL_MASK) - return GP_NON_CANONICAL; + return EXC_NON_CANONICAL; =20 /* * If LASS is active, a NULL pointer dereference generates a #GP * instead of a #PF. */ if (*addr < PAGE_SIZE) - return GP_NULL_POINTER; + return EXC_NULL_POINTER; =20 /* * Assume that LASS caused the exception, because the address is * canonical and in the user half. */ if (cpu_feature_enabled(X86_FEATURE_LASS)) - return GP_LASS_VIOLATION; + return EXC_LASS_VIOLATION; #endif =20 - return GP_CANONICAL; + return EXC_CANONICAL; } =20 #define GPFSTR "general protection fault" @@ -816,7 +816,7 @@ static void gp_user_force_sig_segv(struct pt_regs *regs= , int trapnr, DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) { char desc[sizeof(GPFSTR) + 50 + 2*sizeof(unsigned long) + 1] =3D GPFSTR; - enum kernel_gp_hint hint =3D GP_NO_HINT; + enum kernel_exc_hint hint =3D EXC_NO_HINT; unsigned long gp_addr; =20 if (user_mode(regs) && try_fixup_enqcmd_gp()) @@ -854,17 +854,17 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) if (error_code) snprintf(desc, sizeof(desc), "segment-related " GPFSTR); else - hint =3D get_kernel_gp_address(regs, &gp_addr); + hint =3D get_kernel_exc_address(regs, &gp_addr); =20 - if (hint !=3D GP_NO_HINT) + if (hint !=3D EXC_NO_HINT) snprintf(desc, sizeof(desc), GPFSTR ", %s 0x%lx", - kernel_gp_hint_help[hint], gp_addr); + kernel_exc_hint_help[hint], gp_addr); =20 /* * KASAN is interested only in the non-canonical case, clear it * otherwise. */ - if (hint !=3D GP_NON_CANONICAL) + if (hint !=3D EXC_NON_CANONICAL) gp_addr =3D 0; =20 die_addr(desc, regs, error_code, gp_addr); --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 43758247DE1; Tue, 7 Oct 2025 06:54:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820049; cv=none; b=Ri3FK95Me3yD4Wg/VunhtDcxPilnGnH74evLYwJUgoPNihHl8VeaoQ1tFFzsEQHpMp/xwFRaypvKWs10RPUyDUEha3JnqCya0U4Yw3qQ5yJgo40PUd0PCt8+yi0TLB2lIsXiMyrZHS0f+0+6i5djeOSQ0LNASYg/KXccF52/t1E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820049; c=relaxed/simple; bh=t0DAQB+KC4XHAKaSmSUqvc4zEUTHgxUgLpUaCfDvKeI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P9HC4Q9N5m7SDpuPqNdjXFpnm6/8ysXirjx/5qwbIqMdt6+oAc61HItiWNBKGWn3xD6GmBRCEpGy8nlhJunTWci94jI+tZwgJWGQim7aHJ7Xtzmq9CEPtC1Xp5pTCCBSw83guXgcKz25Pmnh+dR4kx41bu4sgvqt9zqXDp8I/yo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=aTsv+BT5; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="aTsv+BT5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820047; x=1791356047; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=t0DAQB+KC4XHAKaSmSUqvc4zEUTHgxUgLpUaCfDvKeI=; b=aTsv+BT5Gt+7VRmKQY37XtN/ollbootBRhcrB2nVY7XQNxvQpP917kLl oEyJC5QEB2itPQthgnd0GJOS+BJGhwpRTFG7LBKVBjpt0jHMWIulwI1v1 XBcgpEdvwHpN1otKeMyI3AS9EzERVQQ7RCHKkbHuwfk6a0wu9D6NzfX5R 8rR9DMnkm8ZlmLVu5cATu4ze43iCWPZOdAtHsSlIb80Bg5XxNLtCcdMyU /P1foOT5kMNi0ifGq4uIjeSdaf6U+VvIeHZm1tday3uvEHDS/Zz+ZZoWc 3rhz6LD+iZDXprpWsd+eTl3x3MzQFKKvlssESyvZ+ftaPWESoK0jC6PSL Q==; X-CSE-ConnectionGUID: /Ejnlc3STC2ZDFU+QlIl2A== X-CSE-MsgGUID: f6J7PY9RRYChWPLAWYwqAg== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254578" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254578" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:06 -0700 X-CSE-ConnectionGUID: G1brpJMeQxWUcqvyPSqQlw== X-CSE-MsgGUID: dunRP32HRl2MofOuKJdTYA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354518" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:06 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 14/15] x86/traps: Provide additional hints for a kernel stack segment fault Date: Mon, 6 Oct 2025 23:51:18 -0700 Message-ID: <20251007065119.148605-15-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Kirill A. Shutemov" Kernel triggered #SS exceptions are rare, and the faulting instruction may not even have a memory operand. In cases where it does, hints about the cause of the fault can be useful. LASS throws a #GP for any violation except for stack register access, which instead triggers a #SS. Handle a kernel #SS similarly to a #GP and reuse the address decode logic to provide additional hints, such as a non-canonical address or an LASS violation. In case of FRED, before handling #SS as a kernel violation, check if there's a fixup for the exception. Redirect the #SS due to invalid user context on ERETU to userspace. See commit 5105e7687ad3 ("x86/fred: Fixup fault on ERETU by jumping to fred_entrypoint_user") for details. Originally-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Signed-off-by: Sohil Mehta --- v10: - Remove the LASS feature check to always provide hints independent of LASS being enabled. - Update printk to use KERN_DEFAULT (checkpatch warning). - Add code comments. --- arch/x86/kernel/traps.c | 43 +++++++++++++++++++++++++++++++++++------ 1 file changed, 37 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 3ee8a36a4e6a..864c614cddab 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -418,12 +418,6 @@ DEFINE_IDTENTRY_ERRORCODE(exc_segment_not_present) SIGBUS, 0, NULL); } =20 -DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment) -{ - do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS, - 0, NULL); -} - DEFINE_IDTENTRY_ERRORCODE(exc_alignment_check) { char *str =3D "alignment check"; @@ -873,6 +867,43 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) cond_local_irq_disable(regs); } =20 +#define SSFSTR "stack segment fault" + +DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment) +{ + enum kernel_exc_hint hint; + unsigned long exc_addr; + + if (user_mode(regs)) + goto error_trap; + + /* + * With FRED enabled, an invalid user context can lead to an #SS + * trap on ERETU. Fixup the exception and redirect the fault to + * userspace in that case. + */ + if (cpu_feature_enabled(X86_FEATURE_FRED) && + fixup_exception(regs, X86_TRAP_SS, error_code, 0)) + return; + + if (notify_die(DIE_TRAP, SSFSTR, regs, error_code, X86_TRAP_SS, SIGBUS) = =3D=3D NOTIFY_STOP) + return; + + hint =3D get_kernel_exc_address(regs, &exc_addr); + if (hint !=3D EXC_NO_HINT) + printk(KERN_DEFAULT SSFSTR ", %s 0x%lx", kernel_exc_hint_help[hint], exc= _addr); + + /* KASAN only cares about the non-canonical case, clear it otherwise */ + if (hint !=3D EXC_NON_CANONICAL) + exc_addr =3D 0; + + die_addr(SSFSTR, regs, error_code, exc_addr); + return; + +error_trap: + do_error_trap(regs, error_code, SSFSTR, X86_TRAP_SS, SIGBUS, 0, NULL); +} + static bool do_int3(struct pt_regs *regs) { int res; --=20 2.43.0 From nobody Tue Oct 7 20:01:39 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (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 1BCA02586C2; Tue, 7 Oct 2025 06:54:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820050; cv=none; b=DArBFPhpDJbpTntBQWdDL58+9Uxg29PLorZ3dMCCYy0OQiOogYKmSFF2yNjN4sZ8FgvXlAbWHVZXKv8LQM8RZzEKF0Yn2Es3CXTfkX9zEq2bWUHnePBfdzCJ9JRFMe8q65k4reNl5whStnabW0tjhz+catfafx9DQ3b/UVmaDLw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759820050; c=relaxed/simple; bh=jO/CITRZpotiM7BR0pycN3I+eaS0MSM1mW3jR69WgKQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Teir/OEZs2ebpyFQ+R/x4D/qE/y5puZMnBFVm3nImwPYjvBAoqNV1tQBQJj/sqGGmDlh+ej4vapV1ZdICXmHlIEiubB9eQF/QAOzcbD3qWPF44rgfYw5CcXEk2+whqsET7SjohQxzUFtlMDVSvKQMmb0YYbvhOUB1v4EIKgnExQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ZaW6s9Qx; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ZaW6s9Qx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1759820048; x=1791356048; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jO/CITRZpotiM7BR0pycN3I+eaS0MSM1mW3jR69WgKQ=; b=ZaW6s9QxQuP2O5TtMorwFvjGrgfBbkgQKiglyxf6OI4/R0TpSAJEmI7M Zc+916ORkRAMwaTeaf7AdUGJVXUUmbPvACvofTguokJTIE8NR42+0JaoR PnUCO3iwtDBXho+rbu1duOYJcDWBJkRoHLovJPlJVsDRiaznfI1iTYxGO 1D0F1fM5M3HTlcRyiEosqqa5sMIzGOWRGUjEcGWjqyexvDk1EbjuV1i0Q g8SMH2YRsQhGbj/eeXwOiKgRjGqXOTvtoBXiDz/iuMKi/IK72h0iABxHO OY5HSuJf1TNrjKSVvYtBDeZhXMoQ0i9OfIJF/Lf1sk+xfGAJHcFw154fw Q==; X-CSE-ConnectionGUID: QbQ8/xqKSmiJMSmF5zn9FQ== X-CSE-MsgGUID: e7rQdQc0RcayQzZUhQT1VA== X-IronPort-AV: E=McAfee;i="6800,10657,11574"; a="72254595" X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="72254595" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2025 23:54:07 -0700 X-CSE-ConnectionGUID: kSpwjkZBS4egwnjDdYeLNQ== X-CSE-MsgGUID: F5tz/hZmR4Omncq0SUAkqA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,321,1751266800"; d="scan'208";a="184354532" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa004.jf.intel.com with ESMTP; 06 Oct 2025 23:54:06 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , David Laight , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v10 15/15] x86/cpu: Enable LASS by default during CPU initialization Date: Mon, 6 Oct 2025 23:51:19 -0700 Message-ID: <20251007065119.148605-16-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251007065119.148605-1-sohil.mehta@intel.com> References: <20251007065119.148605-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Linear Address Space Separation (LASS) mitigates a class of side-channel attacks that rely on speculative access across the user/kernel boundary. Enable it by default if the platform supports it. While at it, remove the comment above the SMAP/SMEP/UMIP/LASS setup instead of updating it, as the whole sequence is quite self-explanatory. Signed-off-by: Sohil Mehta Reviewed-by: Rick Edgecombe --- v10 - No change. --- arch/x86/kernel/cpu/common.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 57d5824465b0..7f0f1b56cbe7 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -401,6 +401,12 @@ static __always_inline void setup_umip(struct cpuinfo_= x86 *c) cr4_clear_bits(X86_CR4_UMIP); } =20 +static __always_inline void setup_lass(struct cpuinfo_x86 *c) +{ + if (cpu_feature_enabled(X86_FEATURE_LASS)) + cr4_set_bits(X86_CR4_LASS); +} + /* 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 | X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED | @@ -2019,10 +2025,10 @@ static void identify_cpu(struct cpuinfo_x86 *c) /* Disable the PN if appropriate */ squash_the_stupid_serial_number(c); =20 - /* Set up SMEP/SMAP/UMIP */ setup_smep(c); setup_smap(c); setup_umip(c); + setup_lass(c); =20 /* Enable FSGSBASE instructions if available. */ if (cpu_has(c, X86_FEATURE_FSGSBASE)) { --=20 2.43.0