From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 283FC28A1E5; Mon, 7 Jul 2025 08:03:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875414; cv=none; b=GYMInowPh/2YQOS1ftJGe0GQ512vmeFrvKuBANVN0pq42Zc0roeI0orBGvBlxfz0W/Xhd16cuuip2hQHiQE8NQrV3SQZUoZ9vJ60zF59/u887UFSsNXoE28HJm4wok+UZhEPs4+1iCy617rerEO0xsqbL/0zgDEuOlnyH3R8CVE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875414; c=relaxed/simple; bh=+sLhOPcFptW2woVp03R+FsF4pqvxAwrxx4TJdCebibo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FzmbcSbPdH13eX2GclUJBJx7wuVHup+1R1gvwux2pNdqPXMd3DBVb9hHVmdmcOc5qD8J+BpRdHrZUOpU+RX2izsBZiYUfUNEpBHBdytSqlHEdazO1Iki+Px61j2tPBGrtP1C7cWoHFzy3b9KpBCoHV/ZyRp+lVltf9fRXQEixAM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=oHPbF/rT; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="oHPbF/rT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875413; x=1783411413; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+sLhOPcFptW2woVp03R+FsF4pqvxAwrxx4TJdCebibo=; b=oHPbF/rTqMvDYR+Zsj1BPcpqRagO7QKglQ272HJiq1s9v/+oEgeHFlth hqJs9wiY0QDlomidab0FKNIXbyefI5Ll4Rz/vCmcxHE4Y767gR0EJCMij SOcrF9SwFiSe400QerDBtSYWAL7QadsZp/LHQaUsSZ0C/hIBc7wQo8VFZ 39gXLmFezLpiD5Uyx6sUAeuR7I5aQoK1BWaBneUjO1XyREQeMN18zSc+9 TCHtvpLVElX0fRrOGIoBg7KZhpKTPRwG/tvWc5ptcCjB8W7UsBJVYOvrr TaA7SPKT/4PsF6Ksg0LAcUfckKGvEyysiUC+qMWydvae6IjneM1XnAa14 Q==; X-CSE-ConnectionGUID: sVyaZc6yQPyz2wlT/cYEgA== X-CSE-MsgGUID: W5xDcNk7RXugPEroigQ7hQ== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="53807189" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="53807189" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:31 -0700 X-CSE-ConnectionGUID: CKZM73tORg+jMc/8ZlU7xg== X-CSE-MsgGUID: eZ5S2a+ZQ/yYIhLBvbSggQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="160804323" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa005.jf.intel.com with ESMTP; 07 Jul 2025 01:03:19 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 9223615D; Mon, 07 Jul 2025 11:03:17 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 01/16] x86/cpu: Enumerate the LASS feature bits Date: Mon, 7 Jul 2025 11:03:01 +0300 Message-ID: <20250707080317.3791624-2-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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: Sohil Mehta 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. Malicious software can use timing information resulting from this traversal to determine details about the paging structures, and these details may also be used to determine the layout of the kernel memory. The LASS mechanism provides the same mode-based protections as paging but without traversing the paging structures. Because the protections enforced by LASS are applied before paging, software 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 typical 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 access 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 this feature and include feature dependencies to reflect the same. LASS provides protection against a class of speculative attacks, such as SLAM[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 setup is secure against such attacks. [1] https://download.vusec.net/papers/slam_sp24.pdf Co-developed-by: Yian Chen Signed-off-by: Yian Chen Signed-off-by: Sohil Mehta Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Reviewed-by: Borislav Petkov (AMD) Reviewed-by: Xin Li (Intel) --- 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 + tools/arch/x86/include/asm/cpufeatures.h | 1 + 5 files changed, 9 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 b78af55aa22e..8eef1ad7aca2 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -313,6 +313,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 diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/incl= ude/asm/cpufeatures.h index ee176236c2be..4473a6f7800b 100644 --- a/tools/arch/x86/include/asm/cpufeatures.h +++ b/tools/arch/x86/include/asm/cpufeatures.h @@ -313,6 +313,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 */ --=20 2.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 796FC800; Mon, 7 Jul 2025 08:03:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875413; cv=none; b=C7XmW6AHmrFQnV/w1dnCxldohLYOgLm6MLAwC1W6AmsO5Wk3mZ5SI8z5AV18LYB/Tw/kx/orQPHarYm+/Ngz/nOX9n1R+k25RFl59hdTNob9EKF97fpCr0SK+yw3DOXCwcWDRSh2bSmu239BrGlA2R3xpwa6katpTiwmYADE7JU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875413; c=relaxed/simple; bh=g1usd24mzRnTIn8RaPaizytARVjhWOOMWYiw3ko0c9w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cx7fC2qKrtoLJxRELJGqbLoSuNwSGVBTJua89SmdeV98WkX0JSfucfpz3zXGLsWh3zGtVasEQbpR3m4hvbWv4sm1dR4TqHdXiyAtHKCriG3yudTe7gVtaz43hSiWuH1l5krQunMeRv4virpQZHAKuWzkSZuMw8HTp+pblKcDJj8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=bKznEaWz; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="bKznEaWz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875411; x=1783411411; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=g1usd24mzRnTIn8RaPaizytARVjhWOOMWYiw3ko0c9w=; b=bKznEaWzcYMgoRT2Un5r5ixdwIwRNO/k/wzxlCEelOMxf4yBZeKGZIo5 ujw8YPfF6kR7UPyKtfJ+ckVgEnfANjeGStZ6IbN72sNfNKSGJYpfshatB VQABcDp3I+WFafPdtmgTFffcLfYALuqspVwfPIfsOkV7yxQdTTPY3saGY cLtAraoDaTVZMvsJG8Ue0+0xzcBv3paFXOTsSSMCnivF5VYDkdBi+CYe8 HhUeeZRjcFDWpfr8xgMKVQ36kkKomJ0VfDiqAlqCzzl+0LI5Zqj84gWNm +fgkdzOHqm9Rb+2pQ1hnmDOIpU6TPM0N/MUd4TQpkSRlmHSwtemJHEyfQ Q==; X-CSE-ConnectionGUID: WWkoCbj9QTmNDPS854oayw== X-CSE-MsgGUID: EPMaFhT2Qa2SDL7oPWOl2g== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="53807168" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="53807168" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:30 -0700 X-CSE-ConnectionGUID: vyXTIaloR7aLTzXQqPoEKA== X-CSE-MsgGUID: +Ex8rCk0Svq8GLwiRF3otQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="160804321" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa005.jf.intel.com with ESMTP; 07 Jul 2025 01:03:19 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id A0BD01DF; Mon, 07 Jul 2025 11:03:17 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 02/16] x86/alternatives: Disable LASS when patching kernel alternatives Date: Mon, 7 Jul 2025 11:03:02 +0300 Message-ID: <20250707080317.3791624-3-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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: Sohil Mehta For patching, the kernel initializes a temporary mm area in the lower half of the address range. See commit 4fc19708b165 ("x86/alternatives: Initialize temporary mm for patching"). Disable LASS enforcement during patching to avoid triggering a #GP fault. The objtool warns due to a call to a non-allowed function that exists outside of the stac/clac guard, or references to any function with a dynamic function pointer inside the guard. See the Objtool warnings section #9 in the document tools/objtool/Documentation/objtool.txt. Considering that patching is usually small, replace the memcpy() and memset() functions in the text poking functions with their open coded versions. Signed-off-by: Sohil Mehta Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/smap.h | 33 +++++++++++++++++++++++++++++++-- arch/x86/kernel/alternative.c | 28 ++++++++++++++++++++++++++-- 2 files changed, 57 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/smap.h b/arch/x86/include/asm/smap.h index 4f84d421d1cf..d0cc24348641 100644 --- a/arch/x86/include/asm/smap.h +++ b/arch/x86/include/asm/smap.h @@ -23,18 +23,47 @@ =20 #else /* __ASSEMBLER__ */ =20 +/* + * The CLAC/STAC instructions toggle the enforcement of X86_FEATURE_SMAP a= nd + * 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. + * + * 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 sp= ace + * unless the AC bit is set. + * + * Use stac()/clac() when accessing userspace (_PAGE_USER) mappings, + * regardless of location. + * + * Use lass_stac()/lass_clac() when accessing kernel mappings (!_PAGE_USER) + * in the lower half of the address space. + * + * 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 +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 ea1d984166cd..992ece0e879a 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -2447,16 +2447,40 @@ 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. + */ + static void text_poke_memcpy(void *dst, const void *src, size_t len) { - memcpy(dst, src, len); + lass_stac(); + + /* + * Objtool is picky about what occurs within the STAC/CLAC region + * because this code runs with protection disabled. Objtool typically + * does not permit function calls in this area. + * + * Avoid using memcpy() here. Instead, open code it. + */ + asm volatile("rep movsb" + : "+D" (dst), "+S" (src), "+c" (len) : : "memory"); + + 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(); + + /* Open code memset(): make objtool happy. See text_poke_memcpy(). */ + asm volatile("rep stosb" + : "+D" (dst), "+c" (len) : "a" (c) : "memory"); + + lass_clac(); } =20 typedef void text_poke_f(void *dst, const void *src, size_t len); --=20 2.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 BFF9F194098; Mon, 7 Jul 2025 08:03:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875415; cv=none; b=LflI8pXxjZDlk6fQaO9XB2pS1ag1nDkFSqiBgAgVwtIloDmh7VWPn+gh+lcE42kM+39MWENoy2bKGtt+FjtHU/Xngo3ZUZ1TCj7TxYSZNCQZ7OPDSSFL7OKeYXMIrwJC4EiXPnBeFX3YLxMHdEisBiGYnsZa5LLmBcLOvjO0WgQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875415; c=relaxed/simple; bh=J5WwLctxhVnscj924ezQg1UGG/n1vvqksbWY0HLqHYc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gFzTraUgdpyexphE8wUZiXEIUN4FKq3DODUp3xLP3UF4OoPJ4jtcO5PNxhJm5RvAvQMbbuqNspuUOi2kaidey+Rg9GcVhJclxogC0d3XocbITjjCTW7MAOrF3w0qsD1SydM3DjMc8xywwyzXRFNWEQEkVcR9D+s24Yo7fbWv+Qk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=R/gCxRjL; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="R/gCxRjL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875414; x=1783411414; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=J5WwLctxhVnscj924ezQg1UGG/n1vvqksbWY0HLqHYc=; b=R/gCxRjLKhacgTbRLQXax9LX/w+rMqikYvJPDwoUvXvb2kpC2rj1IOSn hv/Scrgj/1FTuHdIsdPl/UI+Vayv/GbMpBgM3I2RVY26Ct7rCAPT3WE4S 89GFRjkneZeX3wi1CU5LzAJkaMO27ggJF9Jbhkm62o5IDT0n8TOGxObpn evXb5h2onLjazNeDooxrNl9lJK5upCLoZ4FxA90qQ8yFtFddbwE0L/doR fVAHcME3c0OpV14mwbYRVcRa3tRo9TcZSGKU59mnNWAOlh/ioBdGmzjR2 2SUO/xu9aE2yFdFaxptCv2fBitkwKyizMTnqRLP57uPixfzs/GONIrLrV Q==; X-CSE-ConnectionGUID: XqtkD405ScCjYDRUeAPc+w== X-CSE-MsgGUID: O7Vc/f9uSVSVDyWsTVCecg== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="65151816" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="65151816" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:32 -0700 X-CSE-ConnectionGUID: Fl3qj04tTyayfhZ22ecZJA== X-CSE-MsgGUID: S+5BXXZmQzm/AV838UcAjw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="154573873" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa010.jf.intel.com with ESMTP; 07 Jul 2025 01:03:20 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id B188E2E7; Mon, 07 Jul 2025 11:03:17 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 03/16] x86/cpu: Set LASS CR4 bit as pinning sensitive Date: Mon, 7 Jul 2025 11:03:03 +0300 Message-ID: <20250707080317.3791624-4-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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: Alexander Shishkin Reviewed-by: Tony Luck Reviewed-by: Sohil Mehta Signed-off-by: Kirill A. Shutemov --- 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 325f892ee42d..ec62e2f9ea16 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.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 53A7E2797AB; Mon, 7 Jul 2025 08:03:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875415; cv=none; b=GBQA3fOZImvJJAyDRMMoqx+CLguh/tZeqHoAP1GGz2O0Gut0x1MN0BvhPdUYjXV/PRot4Y2+YvvBak2R36uJayHnX3gEz2WOMrN6UzxsBAUZDOdFuSYqBDtrKE/NW2xjRQbO5QxcsbOV/pFKQ2Gba3ALYGN3DQ4Mdj5ASISGLvk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875415; c=relaxed/simple; bh=nBTcvBCFvfLYdQ6wA9b5vvQrMmyAcbLEQoeRNyDewSs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cs3oCC00kqbj4rvAD5gBEc43bDx/nsSM5OBszn6RQXgHvW7ZRPqbHqEB1/Q+F/2qmywlKTv4tAsuOtsq59kXIrW433EtCAS0RCXcI9Ye8qpVkbYGNw+OMDt1PpJEZypELjGnxgH4GQE5x0NiOPUR8kHYkJcGLghb+T/4F8zuW70= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=k5T5nC/8; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="k5T5nC/8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875414; x=1783411414; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=nBTcvBCFvfLYdQ6wA9b5vvQrMmyAcbLEQoeRNyDewSs=; b=k5T5nC/8/l6Cqk3ER9LgzZGQTTMXuUtThaiAssOUqTKr4DV3I9WS6TXH 1Jt910A3UWomdNVwisCsKivjG6m3aSViOcDg6c8Xfp6RtmLZEkNwlOyqk ySKXwb25lvXtfu3sKmMb8ipf9gHlD/hQFr+hV2xHi30JSvoPF7MpDFMHj NNHrwbjfUO/T8ZB6qFFvgCCVhRN+jBFghDdId81F6/fiLrBPMa56EfSP0 9XEsiHbp/q+VKvIRXWFP1amnRabxGKPsLdZtZd6FQm8a99cZD2TK3UnBJ 8RpkpSwHitbUhXKzaYdlBEpiwOIGKzMt1tCOTGSf/XjfdqOzqMMgR/fP0 Q==; X-CSE-ConnectionGUID: sUALiPbJSWOjrJ+1oL3oHQ== X-CSE-MsgGUID: E9cznNqIRLS66kEk2DJHkw== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="53807232" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="53807232" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:32 -0700 X-CSE-ConnectionGUID: rQ8sF5jRQ0Ooa7q2UfsTuw== X-CSE-MsgGUID: wfmB6psJQri+O/QKt2floA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="160804328" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa005.jf.intel.com with ESMTP; 07 Jul 2025 01:03:21 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id C3C91386; Mon, 07 Jul 2025 11:03:17 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 04/16] x86/cpu: Defer CR pinning setup until core initcall Date: Mon, 7 Jul 2025 11:03:04 +0300 Message-ID: <20250707080317.3791624-5-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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 In order to map the EFI runtime services, set_virtual_address_map() needs to be called, which resides in the lower half of the address space. This means that LASS needs to be temporarily disabled around this call. This can only be done before the CR pinning is set up. Instead of moving setup_cr_pinning() below efi_enter_virtual_mode() in arch_cpu_finalize_init(), defer it until core initcall. Wrapping efi_enter_virtual_mode() into lass_stac()/clac() is not enough because AC flag gates data accesses, but not instruction fetch. Clearing the CR4 bit is required. Signed-off-by: Alexander Shishkin Suggested-by: Kirill A. Shutemov Signed-off-by: Kirill A. Shutemov Reviewed-by: Sohil Mehta --- arch/x86/kernel/cpu/common.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index ec62e2f9ea16..f10f9f618805 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -490,11 +490,14 @@ void cr4_init(void) * parsed), record any of the sensitive CR bits that are set, and * enable CR pinning. */ -static void __init setup_cr_pinning(void) +static int __init setup_cr_pinning(void) { cr4_pinned_bits =3D this_cpu_read(cpu_tlbstate.cr4) & cr4_pinned_mask; static_key_enable(&cr_pinning.key); + + return 0; } +core_initcall(setup_cr_pinning); =20 static __init int x86_nofsgsbase_setup(char *arg) { @@ -2082,7 +2085,6 @@ static __init void identify_boot_cpu(void) enable_sep_cpu(); #endif cpu_detect_tlb(&boot_cpu_data); - setup_cr_pinning(); =20 tsx_init(); tdx_init(); --=20 2.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 DDC8228A719; Mon, 7 Jul 2025 08:03:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875416; cv=none; b=WV1wg4+bsHMxA3UFuVq5qfiS9qKHb3sHy5lD55QXOuvDvPqfV6MShH/AWpq5eOUTVJleaWrdcmJrLCGcDq46k2hVTlS3rJytTrGVSVh8QPWRL6a2lf+xgNGy4C42A+qXgAWzy8t2F74Lzge1gdzju7FHZnWD4Tk+CwaVQnWj4tQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875416; c=relaxed/simple; bh=G+eP9Bw73xI4j+67SYkgeX9LiSQjfbtHwX1bukiOpM0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ifcBZfuQiklDKEwEcXcLeSHaJoWcrqJz1wry85CwPm+sBcSL48IxVOdzhn3LKF9RWsJaFgIC80ljkz0GA31OHlP7tqYExoo2+vq4UfHMAvXTFNTXHOc9YF0Y8fUkdB9sSzMpwumIn2Z8YZiJRA94p4Prs6VQs9gMdHo0fAV91d8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=eMHGlhxc; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="eMHGlhxc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875415; x=1783411415; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=G+eP9Bw73xI4j+67SYkgeX9LiSQjfbtHwX1bukiOpM0=; b=eMHGlhxcAwWWwxvPsqrDXCR9/yK+W7ZXAjBPFtl5grrW1qLJWBm7MqWl YuY2xl3X+khKmqfm+Vx34y/fGQbMX4co7KQzNfKlhYLb7U9sqlW9vi2nz NMkr8vUpkCGhH4QZRalJ3ZmCt3P9zv3ZqrLs5hfR8cvI1bXukA3Zxq/hi cg9JBHNMfh90LtkYytWXhNyuoBlV4VM1fRyQOpsagMwUIgS++yLMEx2f0 E0rF3EhsZs4jHIgWcLse8Wrn8Hxw3AEH+LIVlneOTWDl81MrnPdYZxnl2 w16481lX9ADIrfdmpbaM7Pvc7c4zOrh9cZKgWEulp07AGf9yZbMb/kfZy Q==; X-CSE-ConnectionGUID: KzEC1U1aTZOOu572vadoqA== X-CSE-MsgGUID: gGCwKlDiRiuiKJgrIsm9bg== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="53807253" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="53807253" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:33 -0700 X-CSE-ConnectionGUID: l5LBmWXXRBig4FBVoq1GFg== X-CSE-MsgGUID: PXuB/gMDQn6i5/7M8condQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="160804330" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa005.jf.intel.com with ESMTP; 07 Jul 2025 01:03:23 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id D1BE1458; Mon, 07 Jul 2025 11:03:17 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 05/16] efi: Disable LASS around set_virtual_address_map() EFI call Date: Mon, 7 Jul 2025 11:03:05 +0300 Message-ID: <20250707080317.3791624-6-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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 Of all the EFI runtime services, set_virtual_address_map() is the only one that is called at its lower mapping, which LASS prohibits regardless of EFLAGS.AC setting. The only way to allow this to happen is to disable LASS in the CR4 register. Disable LASS around this low address EFI call. Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Reviewed-by: Sohil Mehta --- arch/x86/platform/efi/efi.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 463b784499a8..5b23c0daedef 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -787,6 +787,7 @@ static void __init __efi_enter_virtual_mode(void) int count =3D 0, pg_shift =3D 0; void *new_memmap =3D NULL; efi_status_t status; + unsigned long lass; unsigned long pa; =20 if (efi_alloc_page_tables()) { @@ -825,11 +826,25 @@ static void __init __efi_enter_virtual_mode(void) =20 efi_sync_low_kernel_mappings(); =20 + /* + * set_virtual_address_map() is the only service located at lower + * addresses, so LASS has to be disabled around it. + * + * Note that flipping RFLAGS.AC is not sufficient for this, as it only + * permits data accesses and not instruction fetch. The entire LASS + * needs to be disabled. + */ + 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.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 A9E3728A415; Mon, 7 Jul 2025 08:03:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875418; cv=none; b=MtfnpZMgNO0OzNhHOFGYAMTwWSjezPF0Bl9Ovv5gXL0Lsy2JcPuOs8ZY9D0gBox12J/snq6tGEa2FesaSLtGF9BHqQTF7S5Im3j7K7uk7lV4ybfaEkYozN/gJHfIcnLh26s+bYhNtUZePfUrlTOqg7kuzwvtkfR5BoMoE29OO2Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875418; c=relaxed/simple; bh=TQ5RCfOQ/5tuZqESL8hi2WCyzYpg/ALQ/w3Eenbo4Ow=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WppiLaacuUiQ7do+LAFDNFf/wvTWlkx8nw0O23kvKCFHf7J+o7/JjQbb6WR6XA7UhRe5rHumo6CAAoK8feCmLZ4ePSidPOIBHKGj7Mws1Kood0kT09aWGpJeieMRiI8u4gWZTeZ1JomGAVxINIng+v790y9Wim40dDSammUgziU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ZbE/1mdw; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ZbE/1mdw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875417; x=1783411417; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TQ5RCfOQ/5tuZqESL8hi2WCyzYpg/ALQ/w3Eenbo4Ow=; b=ZbE/1mdwoGp2LLyeWuKyA2Q5b/ifBnCveThzVC1bR9bW5vbEw8+4Zuvj ShibzyOeC1hBo1wAeG2cyDUDQSoVJ3PdSA0b+x5hVQFhyXXaUMrXcoLIQ WiFGOtjX5vK+rugqBTobB04DrEVwUTIfCQdaG/4pqFly8FEkQiyWnl7jB UQwLYNud2ikhGrN3wQKv0hbyNfutjbyageTbohLN1zbKQSSVibckhvQI2 7o3PHAzO7v+R1iTs3//e8D65rspJixzFkAgXTgd1eOUTIcBugsrwlzSif w9yYdBooFHQn3zr0zuQcVxU9rfN0WSCKmvhHeiSAhyrEYDWJO51iTuhLJ A==; X-CSE-ConnectionGUID: xMuOhLJNSbKbwrNYt1wPcw== X-CSE-MsgGUID: FwD1DF2VToqslLxoleexdg== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="65151840" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="65151840" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:35 -0700 X-CSE-ConnectionGUID: 8f9o8uP7SKO9SEAW6KuirQ== X-CSE-MsgGUID: xrArNHKXTgiu/mLv9rI62g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="154573882" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa010.jf.intel.com with ESMTP; 07 Jul 2025 01:03:23 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id E39A7493; Mon, 07 Jul 2025 11:03:17 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 06/16] x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall Date: Mon, 7 Jul 2025 11:03:06 +0300 Message-ID: <20250707080317.3791624-7-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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" emulate_vsyscall() expects to see X86_PF_INSTR in PFEC on a vsyscall page fault, but the CPU does not report X86_PF_INSTR if neither X86_FEATURE_NX nor X86_FEATURE_SMEP are enabled. X86_FEATURE_NX should be enabled on nearly all 64-bit CPUs, except for early P4 processors that did not support this feature. Instead of explicitly checking for X86_PF_INSTR, compare the fault address against RIP. On machines with X86_FEATURE_NX enabled, issue a warning if RIP is equal to fault address but X86_PF_INSTR is absent. Originally-by: Dave Hansen Link: https://lore.kernel.org/all/bd81a98b-f8d4-4304-ac55-d4151a1a77ab@inte= l.com Signed-off-by: Kirill A. Shutemov Reported-by: Andrew Cooper Reviewed-by: Andrew Cooper --- arch/x86/entry/vsyscall/vsyscall_64.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index c9103a6fa06e..0b0e0283994f 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -124,7 +124,8 @@ bool emulate_vsyscall(unsigned long error_code, if ((error_code & (X86_PF_WRITE | X86_PF_USER)) !=3D X86_PF_USER) return false; =20 - if (!(error_code & X86_PF_INSTR)) { + /* Avoid emulation unless userspace was executing from vsyscall page: */ + if (address !=3D regs->ip) { /* Failed vsyscall read */ if (vsyscall_mode =3D=3D EMULATE) return false; @@ -136,13 +137,16 @@ bool emulate_vsyscall(unsigned long error_code, return false; } =20 + + /* X86_PF_INSTR is only set when NX is supported: */ + 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. */ =20 - WARN_ON_ONCE(address !=3D regs->ip); - if (vsyscall_mode =3D=3D NONE) { warn_bad_vsyscall(KERN_INFO, regs, "vsyscall attempted with vsyscall=3Dnone"); --=20 2.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 63C1928A417; Mon, 7 Jul 2025 08:03:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875419; cv=none; b=aFtxLkunbH+fYvB80geqBXlcWb4eEMAs44Td9v9M/cZAyyMMZFQO3mRn8GRJm4dKupNwAcKWF7y87h7vd2EmElPDJ3rZgHH6w+pD/V0MQzyha20KoGwtinPxDn+NafbVxkdcdgYuQtBPhS5RM4hDTM+n9komtlNL3Nvm0kZGomQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875419; c=relaxed/simple; bh=AhbyuBrFy6ZhBp5R/WtWxW6rQmI0xvLZeZC7IlrtM/I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Vkidca7wAU4iHXkYldxuMNa8bTHlk502ptlLOjV10PCtc0ORdkDN2Q2koyfj0c8G4g9s1GXmWx0Pah8lVQrxY1s3KedqocsqsP+gWDw6pezd6xEVeY+Jlo5QiMxB3/3R6PUOPD4UJ5lJ2oHk5b3Higl08LFoW8b6X9vicKGzL/o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=SpBZRRlR; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="SpBZRRlR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875417; x=1783411417; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=AhbyuBrFy6ZhBp5R/WtWxW6rQmI0xvLZeZC7IlrtM/I=; b=SpBZRRlRKkFtnh2Z/MUkMKpLRFThnbgZ4nO9tJcVOh9SrclJTaE5QIIF OV5HnX8lmzPoad9kl+Ui8SNFmMdBUldBhw/LX06uRuhqEYtcnD6Bw4O2r eTXcQAbf0H5lZ79Yt0DJbIItCnSLzVyKmg/SiAPg5F3y/vgBR9p9H2SXe OBdMgtDNi41XccjRxuxV6WmCW4UN93kE4eVsC0YmPA6vRxu1DzvQ/YUOA hzsBrybinb1bX72QUez70aAaywbEvvTOHu6NXi9tjzLCHSiulJVjmxetG kiHnCcz0mB2X7zdUvuQph9ug+jv7h3o/EnnSpoPvY4/l5y7W+Y1hSj/ad Q==; X-CSE-ConnectionGUID: lNPtDLFQSemTZNfh7P8VUA== X-CSE-MsgGUID: zmft1Wr9QRyze0D0B9yuug== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="65151863" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="65151863" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:36 -0700 X-CSE-ConnectionGUID: KoJPoinaS1+BrBckUJbdFA== X-CSE-MsgGUID: CDau93p8QGu7rq2DpjpqUw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="154573886" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa010.jf.intel.com with ESMTP; 07 Jul 2025 01:03:24 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id F15AA4B1; Mon, 07 Jul 2025 11:03:17 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 07/16] x86/vsyscall: Reorganize the #PF emulation code Date: Mon, 7 Jul 2025 11:03:07 +0300 Message-ID: <20250707080317.3791624-8-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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: Sohil Mehta Separate out the actual vsyscall emulation from the page fault specific handling in preparation for the upcoming #GP fault emulation. No functional change intended. Signed-off-by: Sohil Mehta Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Acked-by: Dave Hansen --- arch/x86/entry/vsyscall/vsyscall_64.c | 52 ++++++++++++++------------- arch/x86/include/asm/vsyscall.h | 8 ++--- arch/x86/mm/fault.c | 2 +- 3 files changed, 33 insertions(+), 29 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index 0b0e0283994f..25f94ac5fd35 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -112,36 +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; - - /* Avoid emulation unless userspace was executing from vsyscall page: */ - 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: */ - 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. @@ -274,6 +251,33 @@ 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; + + if (address =3D=3D regs->ip) { + /* X86_PF_INSTR is only set when NX is supported: */ + if (cpu_feature_enabled(X86_FEATURE_NX)) + WARN_ON_ONCE(!(error_code & X86_PF_INSTR)); + + return __emulate_vsyscall(regs, address); + } + + /* 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 paramete= r if you need a workaround"); + return false; +} + /* * 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..214977f4fa11 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -14,12 +14,12 @@ 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); +extern bool emulate_vsyscall_pf(unsigned long error_code, + struct pt_regs *regs, unsigned 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.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 6B2EC28CF6F; Mon, 7 Jul 2025 08:03:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875420; cv=none; b=sbmy45gM5sshpcADhid5Kcn56HT77/Wo89SqnA6l55aU9U97KdLtjm4pIRkqk8DyOsLQLShaY19amr2X7Juhv7+M2vrFgZTQAFSWyZ1cWWk1HaybqYCQTVpw1ZykYWhJC7ZS1qwg8XMhDHR8SJmEloegvGxTEVoT/q0HOf3YyrE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875420; c=relaxed/simple; bh=t8X0/YOtocOVv/4f2BHHVZROW1ElynXumE/TE+oeSvs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l8f2VFkCHE16+j/vAXra+A3IdC0RJvLqBI0XLW45sMlugUJQIGgro92WrRZ/iQ4x0wJdOsuEb51iAVZ9C6GhnQ6xZjhUCJI8nbpB/IH7KL3fDVP3pPs0jXLaiJzSbJumEKz0DBEC8dypDgFF+DoJAOIE9Kk8HdaMyHcQ1Ex+JhQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Lte502Uf; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Lte502Uf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875419; x=1783411419; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=t8X0/YOtocOVv/4f2BHHVZROW1ElynXumE/TE+oeSvs=; b=Lte502UfUBkkUrb1VJUauxMj1px1dmnXQBLAZaW1wDF5cB2iLF1wH1fr sCIxFgSsZSCQHKCM0Rwpo6gAVzzMSnw4miVl5d8ValtccHvzZodoNszDt 4t1xf4FM/Ia1t9/rNTkKA0/Bd/uyPe9Yr7wYhmtmjkT+J72QF25uxjG+1 +srX1xpYbqdCOOwT0fxPpbsmCHXsG6lLZsW7Glij6Qodq5FzocI332GtP HXKHDO4wLMYz/f4yZnqwdv1pBGY1nK8d5kFGbzwBsxOQoJE23fVsEhY04 1AceagcZSo1zskl68hf3gp0Y1SNxcTHDtPVIgbmwL1Opu46jj/lnoQlBV Q==; X-CSE-ConnectionGUID: DadANlmER1iQD6ABOino2A== X-CSE-MsgGUID: sfTOQO5xTQuV+W16DKVMtA== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="65151900" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="65151900" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:36 -0700 X-CSE-ConnectionGUID: tFC751MYSGKD/hm/hEajww== X-CSE-MsgGUID: pIunraUpQP2J/DBggpj3GQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="154573889" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa010.jf.intel.com with ESMTP; 07 Jul 2025 01:03:25 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 0A573893; Mon, 07 Jul 2025 11:03:18 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 08/16] x86/traps: Consolidate user fixups in exc_general_protection() Date: Mon, 7 Jul 2025 11:03:08 +0300 Message-ID: <20250707080317.3791624-9-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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: Sohil Mehta 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 Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Acked-by: Dave Hansen --- 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 5a4b21389b1d..80f2ad26363c 100644 --- a/arch/x86/kernel/umip.c +++ b/arch/x86/kernel/umip.c @@ -343,6 +343,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.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 D4B4328DEE9; Mon, 7 Jul 2025 08:03:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875421; cv=none; b=OuHWg5Mpve19rygyWmiYp6LX/42vXVCmdg16n9Z4r3UYLkvWqKD9TQEGfvguyYYH1ciHW9RUU0jragXDsagEZ0D5J7q4mGFRG8MDkhtu1qthl2Fjub1Xe6s0sNDys4N/XxVEt8fztdQobprNBGSdcTuwhZfvpLV0S/oEnJJfL1g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875421; c=relaxed/simple; bh=DIAZJj5ldLfuKNtwYLXLtH1FVL2p+rVK3AHYE2U14Ww=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tGLCdW3i/vkWvJegcsbxkpJ1KTFT57S60bCpgwaYUbwU42BdmrMchHzpCntBqpjdYc5qDH75UxDxoLZ4cti2SIRTGCURp8K+8yuQ8FUx27Rwgb5P3AA7GQR4/NMhgnkydcH3YVNUv1+b7rVbpTCmnMbr5Nb1HVDoVtQXsPhS164= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=gdYEU8Bp; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="gdYEU8Bp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875420; x=1783411420; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=DIAZJj5ldLfuKNtwYLXLtH1FVL2p+rVK3AHYE2U14Ww=; b=gdYEU8BpI9azbGs/LSncx6209on78FW91ay3ciXch9Ye8doG6/RkGFvO r7LVUIk/VkrzZLRqYNJdqPSwBDg/+TMueprA4vqXO6p+TqXhir8Bx5hRU R3XBi43GTIysXxSdJbdlrC6xEKYIlWmXtwhpMml5Ds9HyMc1J4jMGFqaS guY8qWD3NNxUyXPeJxlL2wKdvAhXXWSfJKB3MDs5D/ZX6CzSIcGlW21ZB Rm6oZigBF5J4J3UDi3FmTbhqiJVlO3YpZyZIqeGpdquty0/absfSZzn9F rGreDRhuyQ4YepVAol9HzAP0JNoisGFqQCIAJSOHBe5zNB1xFlymI1bKq Q==; X-CSE-ConnectionGUID: njslmajIRY67rSWV0vVWIw== X-CSE-MsgGUID: hPLWHwz6Qdetg3/hzQpshQ== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="57891104" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="57891104" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:38 -0700 X-CSE-ConnectionGUID: DWgco6NcTvSXPtaW3sZhnA== X-CSE-MsgGUID: SLPDvfJ7SGap0llPVYFmNQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="186171978" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa002.jf.intel.com with ESMTP; 07 Jul 2025 01:03:26 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 16EA28AF; Mon, 07 Jul 2025 11:03:18 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 09/16] x86/vsyscall: Add vsyscall emulation for #GP Date: Mon, 7 Jul 2025 11:03:09 +0300 Message-ID: <20250707080317.3791624-10-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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: Sohil Mehta The legacy vsyscall page is mapped at a fixed address in the kernel address range 0xffffffffff600000-0xffffffffff601000. Prior to LASS being introduced, a legacy vsyscall page access from userspace would always generate a page fault. The kernel emulates the execute (XONLY) accesses in the page fault handler and returns back to userspace with the appropriate register values. Since LASS intercepts these accesses before the paging structures are traversed it generates a general protection fault instead of a page fault. The #GP fault doesn't provide much information in terms of the error code. So, use the faulting RIP which is preserved in the user registers to emulate the vsyscall access without going through complex instruction decoding. Signed-off-by: Sohil Mehta Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov --- 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 25f94ac5fd35..be77385b311e 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 @@ -278,6 +278,18 @@ bool emulate_vsyscall_pf(unsigned long error_code, str= uct pt_regs *regs, return false; } =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 214977f4fa11..4eb8d3673223 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -16,6 +16,7 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root); */ extern bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, unsigned long address); +extern 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, @@ -23,6 +24,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.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 3CDFE290BC8; Mon, 7 Jul 2025 08:03:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875423; cv=none; b=fzJewD5mah+aL0WTJ3F8+pl/Igp0jbtpMtCF0KKnMq6MrdSm2cc/9avVYsOBKYHEqKTf2YopLBE+65dmAQ296LQ6rq2V+WXrdyCO4tawKqez/qYKUhBNyHdCW2nu8MACjOrdbZT6KqA+xBiKqSp37Lo/+bsIBfzN5BPO+HvJqcg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875423; c=relaxed/simple; bh=gRYbIS7Dgh1noZwFu/j8FTMijwGvmqKuvAcfA8tsGH0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l9v5YgFdhF5T9jvzzk16cEBpDluIO8Mz024Kp0Pf+VckG5Tg8AgxwIyME3iAKvz+cIAW22fU3Ry1ZL8901Ma/+J/2JZNgabmI4wLziqKXJFaBaLCqPpW8gPZ4NWYf/wG5iRRKOz+rmUblOLdEEBQQ9QNey3c2K/Ea4ojzNrLf3U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=UBaYF03F; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="UBaYF03F" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875422; x=1783411422; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=gRYbIS7Dgh1noZwFu/j8FTMijwGvmqKuvAcfA8tsGH0=; b=UBaYF03F0NjysC9skS3mKBS6yaJd3ckwmJjiiczgKhE3wgx3s3LJgLb+ fJ5qIFNcuUB8QHawGNQ5K95bld692yvTrcEV7sHpk/ud+zWv1jXLnTlyq HR3B+3o53lxEuyf+p1QKRyxXiYv75eaFULPB/6IrxamJwrwG3hKeafjjj 20gUzwEZX8BlxgZIAB827OF4YsLBVyAiBJtoY6+0FLBrgKMfBvquHbVJz oOEbazX7I7a5N5QncoZe0nPYk6V2WpH5YQfTXsObIALX+TkG6w/mNxgvU xfF7XeBNhpfmG1IxrVKXB40xqsHYVEjnl+zX0wKoK4G3mtEKiU/P3Ot4b A==; X-CSE-ConnectionGUID: jPQlUIbARMCorxELFIJkRA== X-CSE-MsgGUID: 9s1d+18mTFmgF2fKbfWfKA== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="65151926" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="65151926" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:40 -0700 X-CSE-ConnectionGUID: amRPvkuCSDWD/XznO18OUw== X-CSE-MsgGUID: TTwuPwcbSx6N7+L7HeOoXw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="154573894" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa010.jf.intel.com with ESMTP; 07 Jul 2025 01:03:26 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 22C2C8E9; Mon, 07 Jul 2025 11:03:18 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 10/16] x86/vsyscall: Disable LASS if vsyscall mode is set to EMULATE Date: Mon, 7 Jul 2025 11:03:10 +0300 Message-ID: <20250707080317.3791624-11-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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: Sohil Mehta The EMULATE mode of vsyscall maps the vsyscall page into user address space which can be read directly by the user application. This mode has been deprecated recently and can only be enabled from a special command line parameter vsyscall=3Demulate. See commit bf00745e7791 ("x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE") Fixing the LASS violations during the EMULATE mode would need complex instruction decoding since the resulting #GP fault does not include any useful error information and the vsyscall address is not readily available in the RIP. At this point, no one is expected to be using the insecure and deprecated EMULATE mode. The rare usages that need support probably don't care much about security anyway. Disable LASS when EMULATE mode is requested during command line parsing to avoid breaking user software. LASS will be supported if vsyscall mode is set to XONLY or NONE. Signed-off-by: Sohil Mehta Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov --- Documentation/admin-guide/kernel-parameters.txt | 4 +++- arch/x86/entry/vsyscall/vsyscall_64.c | 7 +++++++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio= n/admin-guide/kernel-parameters.txt index f1f2c0874da9..796c987372df 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -7926,7 +7926,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 be77385b311e..d37df40bfb26 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -63,6 +63,13 @@ static int __init vsyscall_setup(char *str) else return -EINVAL; =20 + if (cpu_feature_enabled(X86_FEATURE_LASS) && + vsyscall_mode =3D=3D EMULATE) { + cr4_clear_bits(X86_CR4_LASS); + setup_clear_cpu_cap(X86_FEATURE_LASS); + pr_warn_once("x86/cpu: Disabling LASS support due to vsyscall=3Demulate= \n"); + } + return 0; } =20 --=20 2.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 7C06E293C4E; Mon, 7 Jul 2025 08:03:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875427; cv=none; b=fvFNJQZm9UG8mH1H26PopoZAe9TiwptL1JygcMf/2JA0RjC9Zw0H0MYFnLBbGrHgCwcOG08kyvY7QJfm/SUtqErJa8OluXw/WlhVM2vYMxjQuTRqlNmNejNdeV6pEH5K9mPQEGVH49wlC9QCvFNfVUASrFsNdYdvCG6w3sr4l2U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875427; c=relaxed/simple; bh=m+2FhdUaetES/9CojuoZFSartEN5xSLt9c4CTcF72II=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cXcGD1ltQVczZWWFjV6Ea/Dbr8sz+9+AJt+N//cGz8Esns8q6r32HpGN4uvX+Hj/StxkV115XW1aj/gPA1GzUkFPACup2thzUB6RBzMuk+YvsJfl+rDaFCWSp5KndEYKvRVYbAgX+HAMr4HDJH6zwur5Qh5EitiucMLmuZls8yM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=FMXK1WFj; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="FMXK1WFj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875426; x=1783411426; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=m+2FhdUaetES/9CojuoZFSartEN5xSLt9c4CTcF72II=; b=FMXK1WFjmTJpzSE9lVI6Non7XZp65BBc7U9wp5QQNBWoNVSFiH1udX2h NQ95Ut/F5dznUQUOqWwxM8Xlv0wJwL8UHbeQp++qU1e5iTItsJqZCp29g +W1rHWBE3WquN62NmEwm35uhFoSvcb5sVEIoTiQVBoafkVHuYsDlvRWM2 v7PEor+wimAM5VaJuJtLCL5ob20fPl38/HD2W0udlG0OICkmhMdd7HRZ5 NpkJLsOGbV4fBF9S5A98N7+FLbFO8Te4BeRh/XNWgrJiyo1FHjBrmSAQQ k5uNNsE4siE7++m0JjZrBwOkosEtRAC8AsLuXTEGN53UFFaKVmSaKXbIP Q==; X-CSE-ConnectionGUID: KQrwkobySrGg8jL2Nr6auw== X-CSE-MsgGUID: LyzwfI+hTZOCr+zLb745eQ== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="65151948" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="65151948" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:40 -0700 X-CSE-ConnectionGUID: wQbsEHE6SuWCV2Nk2ryjDg== X-CSE-MsgGUID: /W4eV94GTXa7sKygn/q5aQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="154573896" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa010.jf.intel.com with ESMTP; 07 Jul 2025 01:03:27 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 2BFB4928; Mon, 07 Jul 2025 11:03:18 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 11/16] x86/traps: Communicate a LASS violation in #GP message Date: Mon, 7 Jul 2025 11:03:11 +0300 Message-ID: <20250707080317.3791624-12-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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 Provide a more helpful message on #GP when a kernel side LASS violation is detected. A NULL pointer dereference is reported if a LASS violation occurs due to accessing the first page frame. Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Reviewed-by: Sohil Mehta --- arch/x86/kernel/traps.c | 41 +++++++++++++++++++++++++++++------------ 1 file changed, 29 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 59bfbdf0a1a0..4a4194e1d119 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -636,7 +636,16 @@ 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 "LASS prevented access to address", + [GP_NULL_POINTER] =3D "kernel NULL pointer dereference", }; =20 /* @@ -664,14 +673,23 @@ 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 enabled, NULL pointer dereference generates + * #GP instead of #PF. + */ + if (*addr < PAGE_SIZE) + return GP_NULL_POINTER; + + if (cpu_feature_enabled(X86_FEATURE_LASS)) + return GP_LASS_VIOLATION; #endif =20 return GP_CANONICAL; @@ -833,11 +851,10 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) else hint =3D get_kernel_gp_address(regs, &gp_addr); =20 - if (hint !=3D GP_NO_HINT) + 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.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 102022797AB; Mon, 7 Jul 2025 08:03:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875421; cv=none; b=izJnW2QGnEzK6oi7R8oRxAozIbGrCkG7lt88XWIPaFaR8io4Y4WJ+haaXyNbe7hcwUBawbmHm+ZX4hZOhEAD5MfTPZHnDVIGta3TlimEBTpyfk0VRIDs+gEIe5gHvYgEkgNkokmB/uujExWPcc9K5DMaJkVvIhs4iZJ8Y5zpB1M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875421; c=relaxed/simple; bh=JeSkJUV3cdv7bNcvYQkT6zLEZGmKlSxMDoJgLXtp5FU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iN5p2csRgYejpPVT5lluQLUtRnAQ2ct/6jM/hFZBudKA7nzdukS6LQeZmCEeEKpPGejlsNpVbaPqdI4dxRUMJ5LYBP2a8s0lZU02yoY6z80guz5/HHaVupkkX6IexTPz/vi85EOYhI48i8HSpeVcBwIE/opKVlEjid0AOWIAITI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=O3QzUPH6; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="O3QzUPH6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875420; x=1783411420; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=JeSkJUV3cdv7bNcvYQkT6zLEZGmKlSxMDoJgLXtp5FU=; b=O3QzUPH699LY85K/Y4Ll5b6hYDR1ny9pz2VibqwSJpacXkkb/lDxgjwn DvfgXioRwMPQc1vdovmjGeASmNMp9UhFLSuv5Fb4R8VAIlfXtIO3pYtt8 4rIwVtuzKMhsoVSzGJkYCj6BVjPE11bZ+8QKSWqfPK1ozF1JGJHmrrELG FLVqN6e93BRAvMuuz/yHEhZlbwMkPAq3qYuc61vErIfm27KewXgs8n5SK VZAgTCxVIkB9tM53wjTsahRjzZd+ppTO19kHiuptLMr80cLa3iBL+6Ign DyPk35BSx6GzbsQcgZIxG1rLqZRsVLICTar2kZzi75VLbXn7loNhRm3uV Q==; X-CSE-ConnectionGUID: cjL3D1CrSEadWlxHH/mnzg== X-CSE-MsgGUID: InMQzxUFSGO4qOKZqAISfg== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="57891128" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="57891128" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:39 -0700 X-CSE-ConnectionGUID: WKwvMiHoQbqZAzVx9c7oRQ== X-CSE-MsgGUID: 1odox0lWS0iLMEK0BglNLw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="186171982" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa002.jf.intel.com with ESMTP; 07 Jul 2025 01:03:28 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 394C6983; Mon, 07 Jul 2025 11:03:18 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 12/16] x86/traps: Generalize #GP address decode and hint code Date: Mon, 7 Jul 2025 11:03:12 +0300 Message-ID: <20250707080317.3791624-13-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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" In most cases, an access causing a LASS violation results in a general protection exception (#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 fault (#SS) is generated. Handlers for #GP and #SS will now share code to decode the exception address and retrieve the exception hint string. The helper, enum, and array should be renamed as they are no longer specific to #GP. No functional change intended. Signed-off-by: Kirill A. Shutemov Reviewed-by: Sohil Mehta --- arch/x86/kernel/dumpstack.c | 6 ++-- arch/x86/kernel/traps.c | 58 ++++++++++++++++++------------------- 2 files changed, 32 insertions(+), 32 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 4a4194e1d119..f75d6a8dcf20 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -633,28 +633,28 @@ 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 "LASS prevented access to 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 "LASS prevented access to 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. + * When an uncaught #GP/#SS occurs, try to determine the memory address ac= cessed + * 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-canon= ical. */ -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; @@ -662,37 +662,37 @@ 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 enabled, NULL pointer dereference generates * #GP instead of #PF. */ if (*addr < PAGE_SIZE) - return GP_NULL_POINTER; + return EXC_NULL_POINTER; =20 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" @@ -811,7 +811,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()) @@ -849,18 +849,18 @@ 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.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 61EF1292B51; Mon, 7 Jul 2025 08:03:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875427; cv=none; b=G6SLsfN45QB5SDrR/lrXg5tFTLrzy+oTNNpEPJQMOmo/mBL5wWBEQ23AdoCf19wj7wKMrr6zMy3X8tq3DJuibRBNfJuEBq7y/hLF8a+FmqxpuURkaup6GmmR/j1bf/Wxe5v3ghRqNJk0i1nUjq/LbZfxR27tfobDP/6fR1ZCWHY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875427; c=relaxed/simple; bh=XX7DkX4IOR/Ch8/UgwLSCmQRtWcxwxGhsp1B41b3R5A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Q8cAdjpCru2IsKvXqZ87oEkOml5XQsfuIEqgEH263s8hjCPsp014fM0SuS3+TI3cpVr1TSpKtKtTl+eiWwhDyr9O4aj3nKF2kz2yHXMJbI3XhH4OnL+RCz1UyFUYCI2Sir9+w4hqnSCfD+DMerkRUlg+IG/IYHiPGySA6TZ3+6k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=lPy17BuD; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="lPy17BuD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875425; x=1783411425; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=XX7DkX4IOR/Ch8/UgwLSCmQRtWcxwxGhsp1B41b3R5A=; b=lPy17BuDnMSojFcfkW9SNZHKax2fAGdGNPtwmFFfohyreVCSjz0iZ/mP jeE0VTVTvyJpXL7sprnDxY/CJjLkk2fwXaEWIr+iI0RWdSBEHn/uMrL5e jZPhsaaKCKGYJNZ1iDn0eCUGtk+VNqM+eOb3rth6MyQ24S3CH8Pw6hLy2 dPdQZ3470d+gKhZjkVHkkLxI1Hg8sWBEFZOu2pCDWLbLmucB3g8HcSTu0 gqIinxXkow1/F9OLXaDty33WFBEeEflWQxCNd0MfbrvPiHCB35pWAIc9c gcEIbzVCi20eCMMrlqIuzKMudp/7Uvo2FlJ5VVjALjPmukyEo9R6AJv6E g==; X-CSE-ConnectionGUID: 4LyXtJR9RP6vjp34uTp4DA== X-CSE-MsgGUID: NBMJFFoXQ3mM/p1esHqZkg== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="65151952" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="65151952" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:41 -0700 X-CSE-ConnectionGUID: e22tqOlpTjqG/NAdDICv5w== X-CSE-MsgGUID: UF0/80YaSOG6gdZ8LnMjbQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="154573898" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa010.jf.intel.com with ESMTP; 07 Jul 2025 01:03:29 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 46ECD991; Mon, 07 Jul 2025 11:03:18 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 13/16] x86/traps: Handle LASS thrown #SS Date: Mon, 7 Jul 2025 11:03:13 +0300 Message-ID: <20250707080317.3791624-14-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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" LASS throws a #GP for any violations except for stack register accesses, in which case it throws a #SS instead. Handle this similarly to how other LASS violations are handled. In case of FRED, before handling #SS as LASS violation, kernel has to check if there's a fixup for the exception. It can address #SS due to invalid user context on ERETU. See 5105e7687ad3 ("x86/fred: Fixup fault on ERETU by jumping to fred_entrypoint_user") for more details. Co-developed-by: Alexander Shishkin Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Reviewed-by: Sohil Mehta --- arch/x86/kernel/traps.c | 41 +++++++++++++++++++++++++++++++++++------ 1 file changed, 35 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index f75d6a8dcf20..0f6f187b1a9e 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"; @@ -869,6 +863,41 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) cond_local_irq_disable(regs); } =20 +#define SSFSTR "stack segment" + +DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment) +{ + enum kernel_exc_hint hint; + unsigned long exc_addr; + + if (user_mode(regs)) + goto error_trap; + + if (cpu_feature_enabled(X86_FEATURE_FRED) && + fixup_exception(regs, X86_TRAP_SS, error_code, 0)) + return; + + if (!cpu_feature_enabled(X86_FEATURE_LASS)) + goto error_trap; + + 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(SSFSTR ", %s 0x%lx", kernel_exc_hint_help[hint], exc_addr); + + 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.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 1EC85293C75; Mon, 7 Jul 2025 08:03:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875428; cv=none; b=gwXtkQXfONaNLBr+ZIcrHg5zFT69EpzsVEFGvta2Nt7B3d3n4qIknZqmPCKnEYhJsCG7StqPXSQuxYfdJYsRzyhvHCrxF5V8VI/iFM+JlAX6c9ggz2oSFqv5LVrO8m1dc3316mbe3s62/pLu6qBzwwu3XnB047lsnRfAt85hHf0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875428; c=relaxed/simple; bh=NHjNJyeyoaHBgyvq1fO7NjPZypX9iUv0DN8fJhLnDZg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=r0z7sa2bAP8+KJe7tQ12h9asGFKZCLOxqtwAw4IuklsPJqveQ4DzAWFxWEJllBDDp857z8gRr7EAHJEwxGMH5+dr11W1t3Ga/bGd4lLBV4M7R7nkwzx3W99/vEX2MtBMpKCE2gaA8fp1HygHMqY5kTgEo2KxBt7EAPuXp8q4EMM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=mUaC3QJ+; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="mUaC3QJ+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875427; x=1783411427; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=NHjNJyeyoaHBgyvq1fO7NjPZypX9iUv0DN8fJhLnDZg=; b=mUaC3QJ+4MgGQldZdsEirfwPEuqPdr5UEGG6sx112kUoPVZjr0wUnNnT 83xyF4XtrLiTxCEImyw3w4wIdXCmj1RGMX/TjID2oZb1r2Jgc2y4ilTNa QSjqg8mAVJBk+lZ+PXP6TJekzqr59Mg8BC7CMZASOvMM7+PdzvWJWI1W6 mO8jF7c3qBjMIWK8vqAMJh2tmgrIW76NuG3Wfd/3CmcSDd+14A/CNgQwF JDLcmRKBGcQ7AJv2DznR5sgAaLzw6wfalwpdwstv9Dg0VE5mSCcWhCeXF A6sVDv8OLbTaSsfoQYGvAEx+9Wpz/rI4+VQ5yixbFoAgRnYzpASE0+OYd w==; X-CSE-ConnectionGUID: NCq42qcLSOOPjPSO3aovQA== X-CSE-MsgGUID: eWddtOK7RDWKkS9NBjXJfQ== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="65151974" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="65151974" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:42 -0700 X-CSE-ConnectionGUID: QbZyERTwQveB+rAHFYbJYQ== X-CSE-MsgGUID: 4cfO9IaSQTuu9vH6M/pBbA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="154573904" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa010.jf.intel.com with ESMTP; 07 Jul 2025 01:03:29 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 55183A84; Mon, 07 Jul 2025 11:03:18 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 14/16] x86/cpu: Enable LASS during CPU initialization Date: Mon, 7 Jul 2025 11:03:14 +0300 Message-ID: <20250707080317.3791624-15-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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: Sohil Mehta Being a security feature, enable LASS by default if the platform supports it. While at it, get rid of the comment above the SMAP/SMEP/UMIP/LASS setup instead of updating it to mention LASS as well, as the whole sequence is quite self-explanatory. Signed-off-by: Sohil Mehta Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov --- 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 f10f9f618805..382b687ce7e2 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 | @@ -1978,10 +1984,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.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 BC5F5290DAC; Mon, 7 Jul 2025 08:03:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875424; cv=none; b=UECtdJK83R5c6BYfxvfE5uO3rCjFmhxbgqNlQwwmRorXs+nNlHd7V3slcsjjcJ0gsV/5rsWQcRzGpfEW5trbysDiMg5Be31x4OOSGAa+4I+TaalwHMPt7hmpor1pqOsk5tMlj8QS6MHtENjVnw2cr4e8zcQ75j1GyCpSh4MWekg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875424; c=relaxed/simple; bh=9zPszbQZQjES0k+d8nALovvZoQtbhWaMKlfuK3ZvgbI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XofgkgZQ0NNs+ZtBkMSH95LLNDqg2TLzS8uZdaZcALXIisLhJuAcKcgrPMLNRRboyWUwF0V1b5hBjjsXlFV+xtcSnxPPFR4YxHwy8ziDcmWum69Or2ex9135SYc0YTts0yU1K0cSHRYm9a5aKIZVUbKd7JWDfFEUwzuki5yLRIc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=HXryNsmH; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="HXryNsmH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875423; x=1783411423; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9zPszbQZQjES0k+d8nALovvZoQtbhWaMKlfuK3ZvgbI=; b=HXryNsmHMREvhV+LkrBHsfXq+FbD185FEBonJ1UOvdGsBxqpEomXYtGo 7ux8qwgNGNJiRhvRIqCkJ4tkO9dymOiMd12q6hN6maClbvfSrmAzclo9G 97TqUm9N9r3GGsCK14OlGbRI2vRfAyKJUD5x//2W+jtTzOFk4wiBgFWwS bgwt8eqEVyXTX2zLZfLTXgfoAEGQOAwtTbTpOq5lcgHfAxcXYF7QBCl/I aoB19D9MH8xXlS4ZoZ85c6g1Lr9c1/7jFJMA6SKZGn03f1vjaipk3Iweq CvAATcI2cLmjULOtAwJqajdaXsslPq5SDHvHGsL7rpQNhNbEmH0pPI/Y5 Q==; X-CSE-ConnectionGUID: /nwpYCtqT6Gh0Yr3H0ffMw== X-CSE-MsgGUID: wy5rUS3YQH66xcUDyXGCoQ== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="57891149" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="57891149" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:42 -0700 X-CSE-ConnectionGUID: o7N4f0s0Rp+nVzY0KP0MFQ== X-CSE-MsgGUID: MHWoadKIQDayJn45LK1r9w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="186171987" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa002.jf.intel.com with ESMTP; 07 Jul 2025 01:03:31 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 5F857AA7; Mon, 07 Jul 2025 11:03:18 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 15/16] x86/cpu: Make LAM depend on LASS Date: Mon, 7 Jul 2025 11:03:15 +0300 Message-ID: <20250707080317.3791624-16-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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 To prevent exploits for Spectre based on LAM as demonstrated by the whitepaper [1], make LAM depend on LASS, which avoids this type of vulnerability. [1] https://download.vusec.net/papers/slam_sp24.pdf Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Reviewed-by: Sohil Mehta --- arch/x86/kernel/cpu/cpuid-deps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-d= eps.c index 98d0cdd82574..11bb9ed40140 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -90,6 +90,7 @@ static const struct cpuid_dep cpuid_deps[] =3D { { X86_FEATURE_FRED, X86_FEATURE_LKGS }, { X86_FEATURE_SPEC_CTRL_SSBD, X86_FEATURE_SPEC_CTRL }, { X86_FEATURE_LASS, X86_FEATURE_SMAP }, + { X86_FEATURE_LAM, X86_FEATURE_LASS }, {} }; =20 --=20 2.47.2 From nobody Tue Oct 7 19:59:40 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 9419C29346F; Mon, 7 Jul 2025 08:03:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875426; cv=none; b=Gz1aCjM2RKRqistEYyhDi+JQeZ3sD5DY8su/p7ZiZhwMAS6/8Dsm6t5NMgNhgbAHdAFqrI81gbh/XtblDMV+N/fyYMPrybdq2/BK7HY4VnyFpSO0AiemwNKUgT04P2ULVvyzumhI6ODmBM3lbkY8KzLfx3hFKlV4sV4FdpHfNDg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751875426; c=relaxed/simple; bh=zmJ0SsTgrIsGwH/KhdgcrCgX4qTp57IuWr6AQEqkrvM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gXRcjzLAdMpLnUaCJ+2b2oB+/qPxXCvQRmCQWqjUUQYQAK4GG8Ua8SgnztAUwse/IRVIEYqfWe25/1d4tpofQuW8SSWbB1GD2m2w6xcW6Z5w3kEsnb82u7hRsS+KIyaL6azRDz+SpMEqFBuW6+abMQkZhffcc+IuBgCx6xXbSMg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=R9JeVgnF; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="R9JeVgnF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751875425; x=1783411425; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=zmJ0SsTgrIsGwH/KhdgcrCgX4qTp57IuWr6AQEqkrvM=; b=R9JeVgnF33ux6dCFjWbHNtmVyF+ePU3No+J2GfIHLYxO8DOE2uf6GMM2 w7iYzPtzbAXRcQ36ZAj0Dg2saiEYod8rBgL6U25s7kg4jAnnxyVNIKtM/ kB+V/8ZK/BldukDsYoqjMOOVr/hYykz1o+YsinBfNcV3rNJcvyM1Ib+Th pjjpI2DRSxaiV1KvPx2FpczOT/hx1cgy0nWL3qZc4IXhknmx81z0uYE5w QEUBtJfKxmmrwep8TL9VJidAW1awA2NuOEv9+2hSPmbdkz9ClFwEb1H3R TtOeSpyrx9gzX8yD4DcfCwRvD/deBRceH8otFx9cOjxk+BpVZNWPkLzC7 Q==; X-CSE-ConnectionGUID: jGf0D+X+Tn6S3Lda1D+/Hw== X-CSE-MsgGUID: OuNsnhRdTna6X2RmOVyZ6Q== X-IronPort-AV: E=McAfee;i="6800,10657,11486"; a="57891170" X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="57891170" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2025 01:03:43 -0700 X-CSE-ConnectionGUID: 2AH2cPTGSACdcl2bkvyuZQ== X-CSE-MsgGUID: rhjMIjipQl++rGKx2/3w4w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,293,1744095600"; d="scan'208";a="186171990" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa002.jf.intel.com with ESMTP; 07 Jul 2025 01:03:31 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 6D8F4BC2; Mon, 07 Jul 2025 11:03:18 +0300 (EEST) From: "Kirill A. Shutemov" To: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin Cc: Jonathan Corbet , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [PATCHv9 16/16] x86: Re-enable Linear Address Masking Date: Mon, 7 Jul 2025 11:03:16 +0300 Message-ID: <20250707080317.3791624-17-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> References: <20250707080317.3791624-1-kirill.shutemov@linux.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" This reverts commit 3267cb6d3a174ff83d6287dcd5b0047bbd912452. LASS mitigates the Spectre based on LAM (SLAM) [1] and the previous commit made LAM depend on LASS, so we no longer need to disable LAM at compile time, so revert the commit that disables LAM. Adjust USER_PTR_MAX if LAM enabled, allowing tag bits to be set for userspace pointers. The value for the constant is defined in a way to avoid overflow compiler warning on 32-bit config. [1] https://download.vusec.net/papers/slam_sp24.pdf Signed-off-by: Kirill A. Shutemov Cc: Pawan Gupta Reviewed-by: Sohil Mehta --- arch/x86/Kconfig | 1 - arch/x86/kernel/cpu/common.c | 5 +---- 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 71019b3b54ea..2b48e916b754 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2181,7 +2181,6 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING config ADDRESS_MASKING bool "Linear Address Masking support" depends on X86_64 - depends on COMPILE_TEST || !CPU_MITIGATIONS # wait for LASS help Linear Address Masking (LAM) modifies the checking that is applied to 64-bit linear addresses, allowing software to use of the diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 382b687ce7e2..7ae757498a6f 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2553,11 +2553,8 @@ void __init arch_cpu_finalize_init(void) if (IS_ENABLED(CONFIG_X86_64)) { unsigned long USER_PTR_MAX =3D TASK_SIZE_MAX; =20 - /* - * Enable this when LAM is gated on LASS support if (cpu_feature_enabled(X86_FEATURE_LAM)) - USER_PTR_MAX =3D (1ul << 63) - PAGE_SIZE; - */ + USER_PTR_MAX =3D (-1UL >> 1) & PAGE_MASK; runtime_const_init(ptr, USER_PTR_MAX); =20 /* --=20 2.47.2