From nobody Sun Dec 14 11:15:17 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 5A8203161B3; Wed, 29 Oct 2025 21:06:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771974; cv=none; b=FMFzQHJsXmivPXcBVhT5fU6cGMM1/Cb8PBxOrMHKHRg9wDm7sGfmhEjn1IhzPGt6V0NcoqGWA0CzXKBY9QbiBGkeFYecY359BIn3tzWso08N3bpgpjh2k5BNpIt4FXV8mnfjtpaTR0jyih8tKdCGG3sapIaPkp8JSNp29mr9JFY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771974; c=relaxed/simple; bh=GZa1beWO4jpQv3wxEbsNLlIWVYDJxzg3uVKa586FHhc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=agM/m6RoIqndFhxmfOvNJG72yGyKaEmodfzNk7+slK2wrczJvqVxj/wFzoFc0BVjDQyjW9zQe9UMFta9qinXsepUSFagtnXyJnP6p3JZo1pjEPv+DDV+FGFoPHIRo0mdns85k0pmK6ISAq4nbNrPMC72813go4cYBKNfUtjdyow= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=jxufvlBt; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="jxufvlBt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761771973; x=1793307973; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=GZa1beWO4jpQv3wxEbsNLlIWVYDJxzg3uVKa586FHhc=; b=jxufvlBtFT8//gMjPqLPstS9oiM1zRMb6Hpt8Fi60rBP4wmVwW+Y/QXP MZpqDJXW5Wx32EBSSUcndQXV5163wlXtxDBNCF1Q987ycxiIwiHR5fNfL KaZYUuHExQti8nh8VLjQaott6PYSiAUBB+kt4nQ/Af69Rmr31j2Felc/j JxtLEd2+RWAA774kTyIobgtvWJAqsBlqo6h9pW4qE7AoSpw/W3g38ssXS D+iLQacc2UwD7akmDGOI5YtwyLDnfAkdbbjgAf7/eCUjDiSl89DrTYIC0 bMys5XIwqd+wFRCYmNKOYsUFmCinS+4CGGFg/eQwrR2KSt6WKzm+nPZgP A==; X-CSE-ConnectionGUID: ylEt+4b4RZyTPWSPBzbYNA== X-CSE-MsgGUID: hsuB4Q38Qbi9r+o4REsEIQ== X-IronPort-AV: E=McAfee;i="6800,10657,11597"; a="64002735" X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="64002735" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2025 14:06:11 -0700 X-CSE-ConnectionGUID: I39g/gr5RVqFZ+HSYL59LQ== X-CSE-MsgGUID: /8v8SkanQyqcr4BR4xLWgA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="216431969" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa002.jf.intel.com with ESMTP; 29 Oct 2025 14:06:10 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v11 1/9] x86/cpufeatures: Enumerate the LASS feature bits Date: Wed, 29 Oct 2025 14:03:02 -0700 Message-ID: <20251029210310.1155449-2-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251029210310.1155449-1-sohil.mehta@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Linear Address Space Separation (LASS) is a security feature that mitigates a class of side-channel attacks relying on speculative access across the user/kernel boundary. Privilege mode based access protection already exists today with paging and features such as SMEP and SMAP. However, to enforce these protections, the processor must traverse the paging structures in memory. An attacker can use timing information resulting from this traversal to determine details about the paging structures, and to determine the layout of the kernel memory. LASS provides the same mode-based protections as paging but without traversing the paging structures. Because the protections are enforced prior to page-walks, an attacker will not be able to derive paging-based timing information from the various caching structures such as the TLBs, mid-level caches, page walker, data caches, etc. LASS enforcement relies on the kernel implementation to divide the 64-bit virtual address space into two halves: Addr[63]=3D0 -> User address space Addr[63]=3D1 -> Kernel address space Any data access or code execution across address spaces typically results in a #GP fault, with an #SS generated in some rare cases. The LASS enforcement for kernel data accesses is dependent on CR4.SMAP being set. The enforcement can be disabled by toggling the RFLAGS.AC bit similar to SMAP. Define the CPU feature bits to enumerate LASS. Also, disable the feature at compile time on 32-bit kernels. Use a direct dependency on X86_32 (instead of !X86_64) to make it easier to combine with similar 32-bit specific dependencies in the future. LASS mitigates a class of side-channel speculative attacks, such as Spectre LAM, described in the paper, "Leaky Address Masking: Exploiting Unmasked Spectre Gadgets with Noncanonical Address Translation". Add the "lass" flag to /proc/cpuinfo to indicate that the feature is supported by hardware and enabled by the kernel. This allows userspace to determine if the system is secure against such attacks. Signed-off-by: Sohil Mehta Reviewed-by: Borislav Petkov (AMD) Reviewed-by: Xin Li (Intel) Reviewed-by: Dave Hansen --- v11: - Split the SMAP dependency hunk into a separate patch (patch 2). - Improve commit message. v10: - Do not modify tools/**/cpufeatures.h as those are synced separately. --- arch/x86/Kconfig.cpufeatures | 4 ++++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/uapi/asm/processor-flags.h | 2 ++ 3 files changed, 7 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 4091a776e37a..8d872eb08c16 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -314,6 +314,7 @@ #define X86_FEATURE_SM4 (12*32+ 2) /* SM4 instructions */ #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* "avx_vnni" AVX VNNI instructio= ns */ #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* "avx512_bf16" AVX512 BFLOAT= 16 instructions */ +#define X86_FEATURE_LASS (12*32+ 6) /* "lass" Linear Address Space Separa= tion */ #define X86_FEATURE_CMPCCXADD (12*32+ 7) /* CMPccXADD instructio= ns */ #define X86_FEATURE_ARCH_PERFMON_EXT (12*32+ 8) /* Intel Architectural Per= fMon Extension */ #define X86_FEATURE_FZRM (12*32+10) /* Fast zero-length REP MOVSB */ diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include= /uapi/asm/processor-flags.h index f1a4adc78272..81d0c8bf1137 100644 --- a/arch/x86/include/uapi/asm/processor-flags.h +++ b/arch/x86/include/uapi/asm/processor-flags.h @@ -136,6 +136,8 @@ #define X86_CR4_PKE _BITUL(X86_CR4_PKE_BIT) #define X86_CR4_CET_BIT 23 /* enable Control-flow Enforcement Technology = */ #define X86_CR4_CET _BITUL(X86_CR4_CET_BIT) +#define X86_CR4_LASS_BIT 27 /* enable Linear Address Space Separation supp= ort */ +#define X86_CR4_LASS _BITUL(X86_CR4_LASS_BIT) #define X86_CR4_LAM_SUP_BIT 28 /* LAM for supervisor pointers */ #define X86_CR4_LAM_SUP _BITUL(X86_CR4_LAM_SUP_BIT) =20 --=20 2.43.0 From nobody Sun Dec 14 11:15:17 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 68AD93164DB; Wed, 29 Oct 2025 21:06:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771975; cv=none; b=Lme84lAEpim8fBsR5vr0GqLwJmYo4JvhOa3cuH2t6nFZg1UyeYPgp4KA4rkQlmd1UVecRH/Qo1Aw1/ZT5YtI9Os60328sulI/r9yBXXojCEwaub43fS4qugrTDtJL3h3xrPVAjVr5lc+YdvVKr6nC4esMsMQdMSGkyVQTtnDDgQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771975; c=relaxed/simple; bh=LXJVFUz2Qv2IBhxWy4eXgdpAinFwIk1V8yZkKyzmCX0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hIkCImAlDMXOT1HINwPrSRnaXr/tJ5C4O3UGoQlypc41ATOKcNkPcSJ6f8VDUSwAJAmeFsnQ+ptQcK8m+r62OOvXbvOJLsjCcFEGCNDY+R/yaH+EzM/X02MprlM1rEzRl3m7o196r/tuTdg9G02RsUeJ08yVDz/LpN4vxjCSGLw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=L6VqMoD7; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="L6VqMoD7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761771974; x=1793307974; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=LXJVFUz2Qv2IBhxWy4eXgdpAinFwIk1V8yZkKyzmCX0=; b=L6VqMoD7purJ+ESrZ8TUVna8LgcDWPQcewoeBQ90zw44vwKjPgipAJUG i4h2zLwZAUJXtK8DRcB5LS2PqhLFIdwkIujZ167Ewuu6czSjfVyJm6A/q ozSQ6KFQSmaNKVqJqaPehREvI8jS64ZJ3Jv3ntQBvEdE2BN9GkE1uW2k+ XSefINDFngVAGElzBWL5uaiPN9iL97ypPMY568fK5I2PteZcKkkx2kiV9 UJIeKtQBfPlhAGTF16h3lf5L7JQAgdvTY0UVYZhjR7aCqPL5MO/MWyeSH ddhpPGvKXBXV0wom6enaLrKJ0UT3AJU9Ow4+JF6OsiuoEhFQEdngAeUjX A==; X-CSE-ConnectionGUID: 4IYNbB4bRm+mRM2zeTDOmw== X-CSE-MsgGUID: diQ1DWiCRzGkdhSr0NCu/A== X-IronPort-AV: E=McAfee;i="6800,10657,11597"; a="64002736" X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="64002736" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2025 14:06:12 -0700 X-CSE-ConnectionGUID: lVTJqVoxSKq9OA2xJn5s3g== X-CSE-MsgGUID: IRyOuMI7Roq0H6VNJxnqlQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="216431974" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa002.jf.intel.com with ESMTP; 29 Oct 2025 14:06:11 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v11 2/9] x86/cpu: Add an LASS dependency on SMAP Date: Wed, 29 Oct 2025 14:03:03 -0700 Message-ID: <20251029210310.1155449-3-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251029210310.1155449-1-sohil.mehta@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" With LASS enabled, any kernel data access to userspace typically results in a #GP, or a #SS in some stack-related cases. When the kernel needs to access user memory, it can suspend LASS enforcement by toggling the RFLAGS.AC bit. Most of these cases are already covered by the stac()/clac() pairs used to avoid SMAP violations. Even though LASS could potentially be enabled independently, it would be very painful without SMAP and the related stac()/clac() calls. There is no reason to support such a configuration because all future hardware with LASS is expected to have SMAP as well. Also, the STAC/CLAC instructions are architected to: #UD - If CPUID.(EAX=3D07H, ECX=3D0H):EBX.SMAP[bit 20] =3D 0. So, make LASS depend on SMAP to conveniently reuse the existing AC bit toggling already in place. Note: Additional STAC/CLAC would still be needed for accesses such as text poking which are not flagged by SMAP. This is because such mappings are in the lower half but do not have the _PAGE_USER bit set which SMAP uses for enforcement. Signed-off-by: Sohil Mehta Reviewed-by: Dave Hansen --- v11: - New patch (split from patch 1). --- 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 46efcbd6afa4..98d0cdd82574 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -89,6 +89,7 @@ static const struct cpuid_dep cpuid_deps[] =3D { { X86_FEATURE_SHSTK, X86_FEATURE_XSAVES }, { X86_FEATURE_FRED, X86_FEATURE_LKGS }, { X86_FEATURE_SPEC_CTRL_SSBD, X86_FEATURE_SPEC_CTRL }, + { X86_FEATURE_LASS, X86_FEATURE_SMAP }, {} }; =20 --=20 2.43.0 From nobody Sun Dec 14 11:15:17 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 B1E8731691D; Wed, 29 Oct 2025 21:06:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771975; cv=none; b=VHW5M1IwEMKpAk4AVUcvoqsfwLyUIL0vpXmirzqmrRG+Zjb5A08elzqWtZowmO2EEySiT0z2obDpTXIET4AAn1mfq0qYbyh48yinAhQszKoS3SkmYXNN6sCK/OtZjyF/fMyeoxP8IxahHgybPlHbVXb5DhI90+WRUyaleLbODcI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771975; c=relaxed/simple; bh=uSGyq6NaJAJWKU0OwXuVARSCw8j3QBWt7UGMaozfQNc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XuPVuJ/1ZVpkoupsleDmOqzPNB2iwl1tLTSNN0LG1SuEKJ8/n3yiTzA8ZLpb6r2nq2QBOR590aXZ/o5Xj58aSTLzf+KqFSWam2F9qNMelBNK8e33SflFAj9dnhOoD+SXw1HWo7yvk8ZQ/uEUUp06/jpjG2APPEkH+gOO1krW5eY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=hTSVAEqW; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="hTSVAEqW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761771974; x=1793307974; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=uSGyq6NaJAJWKU0OwXuVARSCw8j3QBWt7UGMaozfQNc=; b=hTSVAEqWZz0C/ymJ5R83QSq58mLAQixISOxfad7rLdSn4JRsPB3Tc8KU LNkCdmsjScw7dFtdtwD60Yn6guU6aeJn4PgU9dCcn80MYBUf6z2q/pNjN SrJbDHJKd1SmW73yMbWJH8pxKeP1PLFRw7qg9pfOmCA/lYDgzz5ra08o2 zjJS8mqHuv4UoEG2p7m6V0fjUv8Jc3Aqd+RzfbBz9DIRfqRQPmK0hbKoA HVHZ0ESUigG9s35EplX2fDU/7gFj/5r/GaMNjdclfLW4HvSLIg50CpVp9 mR6HAcV4qYhVR9X2SigdjIyem7T77ZI5LaW0mgd78IREpWikfgs8U8VhQ A==; X-CSE-ConnectionGUID: 77q1L+efRo+x2ak/v4LjdQ== X-CSE-MsgGUID: XkRg1IKvRb+sqOf9my9eoA== X-IronPort-AV: E=McAfee;i="6800,10657,11597"; a="64002738" X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="64002738" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2025 14:06:13 -0700 X-CSE-ConnectionGUID: dMuee8NeRHmc2KZn3Dqlyw== X-CSE-MsgGUID: DrKtsqttS6SjIDHiYErX1A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="216431981" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa002.jf.intel.com with ESMTP; 29 Oct 2025 14:06:12 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v11 3/9] x86/asm: Introduce inline memcpy and memset Date: Wed, 29 Oct 2025 14:03:04 -0700 Message-ID: <20251029210310.1155449-4-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251029210310.1155449-1-sohil.mehta@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Peter Zijlstra (Intel)" Provide inline memcpy and memset functions that can be used instead of the GCC builtins when necessary. The immediate use case is for the text poking functions to avoid the standard memcpy()/memset() calls because objtool complains about such dynamic calls within an AC=3D1 region. See tools/objtool/Documentation/objtool.txt, warning #9, regarding function calls with UACCESS enabled. Some user copy functions such as copy_user_generic() and __clear_user() have similar rep_{movs,stos} usages. But, those are highly specialized and hard to combine or reuse for other things. Define these new helpers for all other usages that need a completely unoptimized, strictly inline version of memcpy() or memset(). Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Sohil Mehta Reviewed-by: Dave Hansen --- v11: - Improve commit log. v10: - Reintroduce the simpler inline patch (dropped in v8). --- arch/x86/include/asm/string.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h index c3c2c1914d65..9cb5aae7fba9 100644 --- a/arch/x86/include/asm/string.h +++ b/arch/x86/include/asm/string.h @@ -1,6 +1,32 @@ /* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_X86_STRING_H +#define _ASM_X86_STRING_H + #ifdef CONFIG_X86_32 # include #else # include #endif + +static __always_inline void *__inline_memcpy(void *to, const void *from, s= ize_t len) +{ + void *ret =3D to; + + asm volatile("rep movsb" + : "+D" (to), "+S" (from), "+c" (len) + : : "memory"); + return ret; +} + +static __always_inline void *__inline_memset(void *s, int v, size_t n) +{ + void *ret =3D s; + + asm volatile("rep stosb" + : "+D" (s), "+c" (n) + : "a" ((uint8_t)v) + : "memory"); + return ret; +} + +#endif /* _ASM_X86_STRING_H */ --=20 2.43.0 From nobody Sun Dec 14 11:15:17 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 41F06318135; Wed, 29 Oct 2025 21:06:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771976; cv=none; b=D8KGcY3zB2QfUVwyRhAExZbpkEWlZT18aatfjusuV8LJ1cJ5B0DmaFPD9TWBJ1Y2kH8CGFq9Sa3rExJWMHC2mdLcZx+WOcBuRnE8EGv6DhJSntFCZWKvJZrkus3+s6LLUhuC/c/cX85Fx1IMMFuMWHXw1YP0tBGbufmo046RJK0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771976; c=relaxed/simple; bh=hVnO1b5BjhuoDuyzGkyBRnDpiZj/eQG7KV9yBG1SLmI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rDt2rBg6C5QMYeOclMYK5UF4MKDr/ORXk/I9VlGgKl33oUw/aM288mZVy/vdNQ1n6Ldz6ME4BoRPI60UNrGfcoDhgKJzRkWZRcy1Gl60A4BKj39BHAKLFk93BUgFyOTXezquiAOI33gXp0+Zmj60fTMNUsqFSQ3UudushySycl8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ND2RNMmL; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ND2RNMmL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761771974; x=1793307974; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=hVnO1b5BjhuoDuyzGkyBRnDpiZj/eQG7KV9yBG1SLmI=; b=ND2RNMmLeVzv4+gxy6nd81Zsus/H2K5vHKxCCnth+EqVb1UoEFafE7+I O5YkUijX2zuvFGxv+U1LgGjVY7IaWJl5FEYK6S1ED3Zs13sQHNrnpl4Ak p+ZrXKS1lRYaewGV9GgDKHyWp2aM4Tl2nxweS9/UdsycbhCLVAlL1q6gr 90IPeygWD3hRdrHlMb9yilSwvXyqZ5Tc03SKU4GvKIfkp0rsfGpQ1AS6t QXLCadSqGA2W7uTVm2ipUxJVSaB2hxCINKIko2vl/V469igvtawx0F2sn CUIHm7Q/bIPTdVHsRrSvPmW9yOqMCjaaMpJiVJGRFE71tw72IQXa+g0G2 w==; X-CSE-ConnectionGUID: DXsPXNvlR1S304Q8CEh+aQ== X-CSE-MsgGUID: OrkTrluDQ5e0uB9ywG2DWQ== X-IronPort-AV: E=McAfee;i="6800,10657,11597"; a="64002739" X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="64002739" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2025 14:06:13 -0700 X-CSE-ConnectionGUID: Cv0k/yrMTzeen3nRR24P4w== X-CSE-MsgGUID: A2CmuLODQBanbse6Ej/4qA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="216431991" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa002.jf.intel.com with ESMTP; 29 Oct 2025 14:06:12 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v11 4/9] x86/alternatives: Disable LASS when patching kernel code Date: Wed, 29 Oct 2025 14:03:05 -0700 Message-ID: <20251029210310.1155449-5-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251029210310.1155449-1-sohil.mehta@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For patching, the kernel initializes a temporary mm area in the lower half of the address range. LASS blocks these accesses because its enforcement relies on bit 63 of the virtual address as opposed to SMAP which depends on the _PAGE_BIT_USER bit in the page table. Disable LASS enforcement by toggling the RFLAGS.AC bit during patching to avoid triggering a #GP fault. Introduce LASS-specific STAC/CLAC helpers to set the AC bit only on platforms that need it. Clarify the usage of the new helpers versus the existing stac()/clac() helpers for SMAP. The Text poking functions use standard memcpy()/memset() while patching kernel code. However, objtool complains about calling such dynamic functions within an AC=3D1 region. See warning #9, regarding function calls with UACCESS enabled, in tools/objtool/Documentation/objtool.txt. To pacify objtool, one option is to add memcpy() and memset() to the list of allowed-functions. However, that would provide a blanket exemption for all usages of memcpy() and memset(). Instead, replace the standard calls in the text poking functions with their unoptimized, always-inlined versions. Considering that patching is usually small, there is no performance impact expected. Signed-off-by: Sohil Mehta Reviewed-by: Dave Hansen --- v11: - Use lass_enable()/lass_disable() naming. - Improve commit log and code comments. v10: - Revert to the inline functions instead of open-coding in assembly. - Simplify code comments. --- arch/x86/include/asm/smap.h | 41 +++++++++++++++++++++++++++++++++-- arch/x86/kernel/alternative.c | 18 +++++++++++++-- 2 files changed, 55 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/smap.h b/arch/x86/include/asm/smap.h index 4f84d421d1cf..90f178c78f9c 100644 --- a/arch/x86/include/asm/smap.h +++ b/arch/x86/include/asm/smap.h @@ -23,18 +23,55 @@ =20 #else /* __ASSEMBLER__ */ =20 +/* + * The CLAC/STAC instructions toggle the enforcement of + * X86_FEATURE_SMAP along with 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 that bit set + * unless the AC bit is set. + * + * Use stac()/clac() when accessing userspace (_PAGE_USER) mappings, + * regardless of location. + * + * Note: a barrier is implicit in alternative(). + */ + static __always_inline void clac(void) { - /* Note: a barrier is implicit in alternative() */ alternative("", "clac", X86_FEATURE_SMAP); } =20 static __always_inline void stac(void) { - /* Note: a barrier is implicit in alternative() */ alternative("", "stac", X86_FEATURE_SMAP); } =20 +/* + * LASS enforcement is based on bit 63 of the virtual address. The + * kernel is not allowed to touch memory in the lower half of the + * virtual address space. + * + * Use lass_disable()/lass_enable() to toggle the AC bit for kernel data + * accesses (!_PAGE_USER) that are blocked by LASS, but not by SMAP. + * + * Even with the AC bit set, LASS will continue to block instruction + * fetches from the user half of the address space. To allow those, + * clear CR4.LASS to disable the LASS mechanism entirely. + * + * Note: a barrier is implicit in alternative(). + */ + +static __always_inline void lass_enable(void) +{ + alternative("", "clac", X86_FEATURE_LASS); +} + +static __always_inline void lass_disable(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 8ee5ff547357..b38dbf08d5cd 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -2469,16 +2469,30 @@ void __init_or_module text_poke_early(void *addr, c= onst void *opcode, __ro_after_init struct mm_struct *text_poke_mm; __ro_after_init unsigned long text_poke_mm_addr; =20 +/* + * Text poking creates and uses a mapping in the lower half of the + * address space. Relax LASS enforcement when accessing the poking + * address. + * + * objtool enforces a strict policy of "no function calls within AC=3D1 + * regions". Adhere to the policy by using inline versions of + * memcpy()/memset() that will never result in a function call. + */ + static void text_poke_memcpy(void *dst, const void *src, size_t len) { - memcpy(dst, src, len); + lass_disable(); + __inline_memcpy(dst, src, len); + lass_enable(); } =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_disable(); + __inline_memset(dst, c, len); + lass_enable(); } =20 typedef void text_poke_f(void *dst, const void *src, size_t len); --=20 2.43.0 From nobody Sun Dec 14 11:15:17 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 1DA553191D3; Wed, 29 Oct 2025 21:06:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771976; cv=none; b=JsOAPX2TO/aQ0o20wDyhDKPWf4Z6hfXT4ai62Ep2Aj/1xPPSLhB/D5KRCZuGHt4fEUoMuREJzhW95L09T9/omE3+aqrLYvhh5STpEGqsnUN3ZHCPEutNdYTzsAE3LYhF8sxkckFCcJgbGfTki8OCNapaYZdTqFNC8n3BleBHcZc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771976; c=relaxed/simple; bh=HFOpNTSEleSAxxj2SXmcUD5+5b9kLLItHL4d1xcvcZc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=S4qjpwPHuCpE9THA01yHcxxySgo7G5rOxCn9yx7MO11mRmQ+ZkTZbwqUm1ntydPm2Kh4ybObteo/fXkFwZRS60Km7RAf+0Q3isRftKbnvh465/yrvGUaK61eZ05u4Qt6mvDnulQlH2onPSOzLNj+GM6lSR8AnbUzUSo6YkQznQ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=A+Q9Dmkr; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="A+Q9Dmkr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761771975; x=1793307975; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HFOpNTSEleSAxxj2SXmcUD5+5b9kLLItHL4d1xcvcZc=; b=A+Q9DmkrFvs9DX14O5ob0m/utcgnsjcFLxOWeeWrcpyefqwlyIVq8A6m WBqW/vkZUFgWXgcPcwZEWGE/T8adtFRcnhgMijIs+hQRrhEsdvnE31fNp DOP9Fvo5O/+enNv9BB4XZLahPKd9Vj7xNy1jzoCB/BCbQTFSNCud26Izy dOwHlEQvWqicFeqN0IhqUxF5n0FfqaAnsHc4XZFv78beHlYySKElqiZol jPupvb0LqEs0ji+hoo6UaCSykCeNxZZ1Frv8y5Je2O/3DdOPVpelO20tC aRCrMcgT5N6dRizTHUXPcFbhIxnph/hm/3M9sp97TU4sjxW25Z2N17yeT Q==; X-CSE-ConnectionGUID: O5NKU0YtSBezzKkionRrcw== X-CSE-MsgGUID: S9bIbtwJQIK7YhQi8v5VNg== X-IronPort-AV: E=McAfee;i="6800,10657,11597"; a="64002741" X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="64002741" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2025 14:06:14 -0700 X-CSE-ConnectionGUID: MOf5mUcgTuebakYZECCDkQ== X-CSE-MsgGUID: MFrmOZI+RZWc0A6fWrPvcA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="216431994" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa002.jf.intel.com with ESMTP; 29 Oct 2025 14:06:13 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v11 5/9] x86/efi: Disable LASS while mapping the EFI runtime services Date: Wed, 29 Oct 2025 14:03:06 -0700 Message-ID: <20251029210310.1155449-6-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251029210310.1155449-1-sohil.mehta@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexander Shishkin While mapping EFI runtime services, set_virtual_address_map() is called at its lower mapping, which LASS prohibits. Wrapping the EFI call with lass_disable()/_enable() is not enough, because the AC flag only controls data accesses, and not instruction fetches. Use the big hammer and toggle the CR4.LASS bit to make this work. Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Signed-off-by: Sohil Mehta --- v11: - No change. v10: - Reword code comments --- arch/x86/platform/efi/efi.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 463b784499a8..ad9f76f90581 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -786,8 +786,8 @@ static void __init __efi_enter_virtual_mode(void) { int count =3D 0, pg_shift =3D 0; void *new_memmap =3D NULL; + unsigned long pa, lass; efi_status_t status; - unsigned long pa; =20 if (efi_alloc_page_tables()) { pr_err("Failed to allocate EFI page tables\n"); @@ -825,11 +825,23 @@ static void __init __efi_enter_virtual_mode(void) =20 efi_sync_low_kernel_mappings(); =20 + /* + * LASS complains because set_virtual_address_map() is located + * at a lower address. To pause enforcement, flipping RFLAGS.AC + * is not sufficient, as it only permits data access and not + * instruction fetch. Disable the entire LASS mechanism. + */ + lass =3D cr4_read_shadow() & X86_CR4_LASS; + cr4_clear_bits(lass); + status =3D efi_set_virtual_address_map(efi.memmap.desc_size * count, efi.memmap.desc_size, efi.memmap.desc_version, (efi_memory_desc_t *)pa, efi_systab_phys); + + cr4_set_bits(lass); + if (status !=3D EFI_SUCCESS) { pr_err("Unable to switch EFI into virtual mode (status=3D%lx)!\n", status); --=20 2.43.0 From nobody Sun Dec 14 11:15:17 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 7E187319609; Wed, 29 Oct 2025 21:06:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771977; cv=none; b=F5nC37pMGNjMktY6NqngpSGOICFRwUNvuPo96LLtep5rI/A3NbK7hgLutpLUyNDXVQDH+loE5J6I5wZdoI4UXa6nWWVYYCOjzj1Eo8GlzI4oh8vlcjMUmPthO9wB+ScO2ZcVkN1R69wSJr8Q/ghm7BqYys7JfWNIZjwwqAxnB84= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771977; c=relaxed/simple; bh=RWXHUqY7TWZ+J1qtks3FVxDXc89CRjSLve0F0cWVWj8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HwjiYoBD+WyFO4qVBSh9XZ9Y5N3zdG7NIV4T/dNBBarSq6MFRPV6q8BYHIDjCuGtAks+oYG1dDT8+VUCKACLhBtrhZMmi5OAOyKACgIBUVuT+mAOQ16YHNXM8Qg3YxwInAfjuXL8YVvH1AgO2RNak16CtR3OfhPVWjp1z+xQvGQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=cjBYlB7t; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="cjBYlB7t" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761771976; x=1793307976; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=RWXHUqY7TWZ+J1qtks3FVxDXc89CRjSLve0F0cWVWj8=; b=cjBYlB7t3G7oSfGPc7megZT+KI2y7O0snaNDJPzMSzJ0w/Ir/mftrKiT sbaQBsfvrjt4q3vyCEXH+0+OWDsmHEJxKM8uTGh1+J6ng7FoiV5b5Jt7F TGyBt858I8mI7+YVY94telsEFWSVVftu1QGMSOhowqZyrfGqjrq63rTac VYGB8fAQctcNdD1lmj2zlb1yAdCq9q5WVRW2siFzhAi+Pc5l2ah2VAqYj S9muQDX8qCYVofU6Q0Sf2YePU72cfWinwKKa9c9Hn7R4X7uBxwHP6VNXd jN97jOPHdLofX0qKFVE2y3Iamd0d0vjV8sdrHpABWEWTyQDtNGPOSZluN w==; X-CSE-ConnectionGUID: 038CFlQBS8um0nlK/7L8Gg== X-CSE-MsgGUID: 2Jv29ZqSSim1vEG0V/z1nA== X-IronPort-AV: E=McAfee;i="6800,10657,11597"; a="64002742" X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="64002742" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2025 14:06:14 -0700 X-CSE-ConnectionGUID: hMP5CQsBRr2dAuMSbnMhFA== X-CSE-MsgGUID: MbtjtTbmR1uC0TqlHkfhjQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="216431999" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa002.jf.intel.com with ESMTP; 29 Oct 2025 14:06:14 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v11 6/9] x86/kexec: Disable LASS during relocate kernel Date: Wed, 29 Oct 2025 14:03:07 -0700 Message-ID: <20251029210310.1155449-7-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251029210310.1155449-1-sohil.mehta@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The relocate kernel mechanism uses an identity mapping to copy the new kernel, which leads to a LASS violation when executing from a low address. LASS must be disabled after the original CR4 value is saved because kexec paths that preserve context need to restore CR4.LASS. But, disabling it along with CET during identity_mapped() is too late. So, disable LASS immediately after saving CR4, along with PGE, and before jumping to the identity-mapped page. Signed-off-by: Sohil Mehta Reviewed-by: Dave Hansen --- v11: - Improve commit message. v10: - New patch to fix an issue detected during internal testing. --- arch/x86/kernel/relocate_kernel_64.S | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocat= e_kernel_64.S index 11e20bb13aca..4ffba68dc57b 100644 --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -95,9 +95,12 @@ SYM_CODE_START_NOALIGN(relocate_kernel) /* Leave CR4 in %r13 to enable the right paging mode later. */ movq %cr4, %r13 =20 - /* Disable global pages immediately to ensure this mapping is RWX */ + /* + * Disable global pages immediately to ensure this mapping is RWX. + * Disable LASS before jumping to the identity mapped page. + */ movq %r13, %r12 - andq $~(X86_CR4_PGE), %r12 + andq $~(X86_CR4_PGE | X86_CR4_LASS), %r12 movq %r12, %cr4 =20 /* Save %rsp and CRs. */ --=20 2.43.0 From nobody Sun Dec 14 11:15:17 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 7843D31C58E; Wed, 29 Oct 2025 21:06:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771978; cv=none; b=lNUTxeZ2HnkbyHpFAyUcLLD2FJtpjHog2uUVaS8qOYr2xYx46i71myiijMqsg04a94M/gaYo7rsErO1reupBpsvVo46OjexYXmAEgxSTDnMthbaMdcbuipdTliHyrWyRvNV5+wyXEIoUD/0fzhV/W5Y2M/AGjOuiY+B2uuSVltM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771978; c=relaxed/simple; bh=wwQQCNi8H/JsqJV/nx2+iP3dZDBjDCblP8QvGNVggWA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G+o+0tzyz+mk7BdTMe8/U2niigX49VbVtqZUudBoeyrTLoQdR/pONcRHGQ23j3ECOPNKiEsZyV7donvk1ve817hDyoqtsKg59gikRENBR3iLCLvUNXPId9p52U0UMPCl9lfx+wYAYCnsxAZEholgkqyFLyByYIo4gUX2B3a4J0w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=egEC0Mwm; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="egEC0Mwm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761771977; x=1793307977; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=wwQQCNi8H/JsqJV/nx2+iP3dZDBjDCblP8QvGNVggWA=; b=egEC0MwmuYayyIoP/S/SDFboEA9s4SUOSrE9wnu9eSI7qkxEJDhKzO2m Ap3wJqparBE1AYl4AY9lr+KDvWHZHMFbJK9OgnHJQfyyvejTNHeS/HZsA VktJR/2T6q3zQRRbP2xwSy/0Y3i207QNpwJ7CsltFlpHxAvHKaiAdyv45 pz6iRRDGIkOPQLnMfPZGYFIujSDiLJTOW5+3MG58vLx2Jbxw6jp0P3r/X ZjX96uRgfhuLmHY7oD4ogK7h08uIcoXCa+HSpVNAieKCF/0cw7yYcKqAg ZbW8mqOXNM+dPAbequHdoWt6r/FTZ+BVoEG2stxfpkbLOQv0yGxZ4Mmx1 g==; X-CSE-ConnectionGUID: h9WsjTkdSOSn3crNLMHKGA== X-CSE-MsgGUID: mCokZYUkT4y6caV/ZVwi4g== X-IronPort-AV: E=McAfee;i="6800,10657,11597"; a="64002743" X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="64002743" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2025 14:06:15 -0700 X-CSE-ConnectionGUID: uGrXlBUiT7uTxu0ezlPFeQ== X-CSE-MsgGUID: bEV/d0/STi6UXTrhZdAqeg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="216432005" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa002.jf.intel.com with ESMTP; 29 Oct 2025 14:06:14 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v11 7/9] x86/traps: Communicate a LASS violation in #GP message Date: Wed, 29 Oct 2025 14:03:08 -0700 Message-ID: <20251029210310.1155449-8-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251029210310.1155449-1-sohil.mehta@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexander Shishkin A LASS violation typically results in a #GP. With LASS active, any invalid access to user memory (including the first page frame) would be reported as a #GP, instead of a #PF. Unfortunately, the #GP error messages provide limited information about the cause of the fault. This could be confusing for kernel developers and users who are accustomed to the friendly #PF messages. To make the transition easier, enhance the #GP Oops message to include a hint about LASS violations. Also, add a special hint for kernel NULL pointer dereferences to match with the existing #PF message. Signed-off-by: Alexander Shishkin Signed-off-by: Kirill A. Shutemov Signed-off-by: Sohil Mehta Reviewed-by: Dave Hansen --- v11: - Improve commit log. v10: - Minor improvement to code comments and hints. --- arch/x86/kernel/traps.c | 45 ++++++++++++++++++++++++++++++----------- 1 file changed, 33 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 6b22611e69cc..30d5c690f9a1 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -635,13 +635,23 @@ DEFINE_IDTENTRY(exc_bounds) enum kernel_gp_hint { GP_NO_HINT, GP_NON_CANONICAL, - GP_CANONICAL + GP_CANONICAL, + GP_LASS_VIOLATION, + GP_NULL_POINTER, +}; + +static const char * const kernel_gp_hint_help[] =3D { + [GP_NON_CANONICAL] =3D "probably for non-canonical address", + [GP_CANONICAL] =3D "maybe for address", + [GP_LASS_VIOLATION] =3D "probably LASS violation for address", + [GP_NULL_POINTER] =3D "kernel NULL pointer dereference", }; =20 /* * When an uncaught #GP occurs, try to determine the memory address access= ed by * the instruction and return that address to the caller. Also, try to fig= ure - * out whether any part of the access to that address was non-canonical. + * out whether any part of the access to that address was non-canonical or + * across privilege levels. */ static enum kernel_gp_hint get_kernel_gp_address(struct pt_regs *regs, unsigned long *addr) @@ -663,14 +673,27 @@ static enum kernel_gp_hint get_kernel_gp_address(stru= ct pt_regs *regs, return GP_NO_HINT; =20 #ifdef CONFIG_X86_64 - /* - * Check that: - * - the operand is not in the kernel half - * - the last byte of the operand is not in the user canonical half - */ - if (*addr < ~__VIRTUAL_MASK && - *addr + insn.opnd_bytes - 1 > __VIRTUAL_MASK) + /* Operand is in the kernel half */ + if (*addr >=3D ~__VIRTUAL_MASK) + return GP_CANONICAL; + + /* The last byte of the operand is not in the user canonical half */ + if (*addr + insn.opnd_bytes - 1 > __VIRTUAL_MASK) return GP_NON_CANONICAL; + + /* + * If LASS is active, a NULL pointer dereference generates a #GP + * instead of a #PF. + */ + if (*addr < PAGE_SIZE) + return GP_NULL_POINTER; + + /* + * Assume that LASS caused the exception, because the address is + * canonical and in the user half. + */ + if (cpu_feature_enabled(X86_FEATURE_LASS)) + return GP_LASS_VIOLATION; #endif =20 return GP_CANONICAL; @@ -833,9 +856,7 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) =20 if (hint !=3D GP_NO_HINT) snprintf(desc, sizeof(desc), GPFSTR ", %s 0x%lx", - (hint =3D=3D GP_NON_CANONICAL) ? "probably for non-canonical address" - : "maybe for address", - gp_addr); + kernel_gp_hint_help[hint], gp_addr); =20 /* * KASAN is interested only in the non-canonical case, clear it --=20 2.43.0 From nobody Sun Dec 14 11:15:17 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 168F431D75B; Wed, 29 Oct 2025 21:06:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771978; cv=none; b=ckv98/fW+mBJkqZNrzx/Wap2AWQS0rf2bzghnZO3bO8+2ckLw8jYDfmEp90yFU96FhAM5cOmxuU+C+FfXOniWemIrPHhOLtCiLKLTr8ra2okw4tjTK1jH2EDH7WHLMAK0kEXs1Z6VKJgLxt6CbtlQ0UHD2Epfh5U7xieUJKPris= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771978; c=relaxed/simple; bh=NOtUdL/MzSIfq6q2T/+8rdhJ1gOmHn5dV1jlrqdAtvw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XYskneE3rOTQnbWjwFcjjQpemhuKdi9cbXn+HRiJi4dwPGgWLPbWFxEk30ssVQlCNfvI3FZCHCLrtaXmoIORvx4IrReLSMQHdQdMbwVVoNqzNXnao3jaYN8MGswsk98XxTlJ9gmlZuGGd+YyhFcRcB+d3DQgiTFussWnEJ+1mao= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=aAVU0klQ; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="aAVU0klQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761771977; x=1793307977; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=NOtUdL/MzSIfq6q2T/+8rdhJ1gOmHn5dV1jlrqdAtvw=; b=aAVU0klQM8lUZM75VUVqX4mM0VDxPBPT0hNue0xyfYkmBs5YoIrX3j63 MhPcUppIF6sQXLtGuB0tFjNubCuW0jiyTy7j7egl0uYuGqMFeMcmFZfRG u6Kic3SRPMgWlxsGWgWKZX6OfLPxRXoL8aTiFQHRuoGYNVSgCjdBewUn7 zSqBbw9C7EdTcnq/LDe/cKGC//pLl9JZv31umm/MpD4I+7OSlhghDm/W2 miG2Cp0hPBAB0lc4En1ClZFDQn3mOvaDJ3OmZgXo9hG4kk+yIGYYy1Qlo zrsUkwuYodbM1K+gVhK6vBh/aAMDRamnLYajKGgCvc3dMkdkJeboLXZ7O Q==; X-CSE-ConnectionGUID: NLYZbWQbRG6+wFRe2SZfrw== X-CSE-MsgGUID: 8LIFBWmiTJeqWDjXsS94Ig== X-IronPort-AV: E=McAfee;i="6800,10657,11597"; a="64002744" X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="64002744" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2025 14:06:16 -0700 X-CSE-ConnectionGUID: fPirA7vTQR2p3uUwT5jJZA== X-CSE-MsgGUID: z1Pc2AcHSr6XGhQ5i8EtKA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="216432014" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa002.jf.intel.com with ESMTP; 29 Oct 2025 14:06:15 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v11 8/9] selftests/x86: Update the negative vsyscall tests to expect a #GP Date: Wed, 29 Oct 2025 14:03:09 -0700 Message-ID: <20251029210310.1155449-9-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251029210310.1155449-1-sohil.mehta@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Some of the vsyscall selftests expect a #PF when vsyscalls are disabled. However, with LASS enabled, an invalid access results in a SIGSEGV due to a #GP instead of a #PF. One such negative test fails because it is expecting X86_PF_INSTR to be set. Update the failing test to expect either a #GP or a #PF. Also, update the printed messages to show the trap number (denoting the type of fault) instead of assuming a #PF. Signed-off-by: Sohil Mehta Reviewed-by: Dave Hansen --- v11: - New patch (Fixes a vsyscall selftest failure) --- tools/testing/selftests/x86/test_vsyscall.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/tools/testing/selftests/x86/test_vsyscall.c b/tools/testing/se= lftests/x86/test_vsyscall.c index 05e1e6774fba..918eaec8bfbe 100644 --- a/tools/testing/selftests/x86/test_vsyscall.c +++ b/tools/testing/selftests/x86/test_vsyscall.c @@ -308,12 +308,13 @@ static void test_getcpu(int cpu) #ifdef __x86_64__ =20 static jmp_buf jmpbuf; -static volatile unsigned long segv_err; +static volatile unsigned long segv_err, segv_trapno; =20 static void sigsegv(int sig, siginfo_t *info, void *ctx_void) { ucontext_t *ctx =3D (ucontext_t *)ctx_void; =20 + segv_trapno =3D ctx->uc_mcontext.gregs[REG_TRAPNO]; segv_err =3D ctx->uc_mcontext.gregs[REG_ERR]; siglongjmp(jmpbuf, 1); } @@ -336,7 +337,8 @@ static void test_vsys_r(void) else if (can_read) ksft_test_result_pass("We have read access\n"); else - ksft_test_result_pass("We do not have read access: #PF(0x%lx)\n", segv_e= rr); + ksft_test_result_pass("We do not have read access (trap=3D%ld, error=3D0= x%lx)\n", + segv_trapno, segv_err); } =20 static void test_vsys_x(void) @@ -347,7 +349,7 @@ static void test_vsys_x(void) return; } =20 - ksft_print_msg("Make sure that vsyscalls really page fault\n"); + ksft_print_msg("Make sure that vsyscalls really cause a fault\n"); =20 bool can_exec; if (sigsetjmp(jmpbuf, 1) =3D=3D 0) { @@ -358,13 +360,14 @@ static void test_vsys_x(void) } =20 if (can_exec) - ksft_test_result_fail("Executing the vsyscall did not page fault\n"); - else if (segv_err & (1 << 4)) /* INSTR */ - ksft_test_result_pass("Executing the vsyscall page failed: #PF(0x%lx)\n", - segv_err); + ksft_test_result_fail("Executing the vsyscall did not fault\n"); + /* #GP or #PF (with X86_PF_INSTR) */ + else if ((segv_trapno =3D=3D 13) || ((segv_trapno =3D=3D 14) && (segv_err= & (1 << 4)))) + ksft_test_result_pass("Executing the vsyscall page failed (trap=3D%ld, e= rror=3D0x%lx)\n", + segv_trapno, segv_err); else - ksft_test_result_fail("Execution failed with the wrong error: #PF(0x%lx)= \n", - segv_err); + ksft_test_result_fail("Execution failed with the wrong error (trap=3D%ld= , error=3D0x%lx)\n", + segv_trapno, segv_err); } =20 /* --=20 2.43.0 From nobody Sun Dec 14 11:15:17 2025 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 59A2B320CD6; Wed, 29 Oct 2025 21:06:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771979; cv=none; b=q6sh9Zpq6bO80KzgBtCUpmR5V32ehb/Tgf0julnhs5Uq+pEzqkQ4bEM01Pn1pBcp+bjz0sqvTdZSed8Fp1PAPLNO+7PgT2nhKXcUTomPr69Hr+dJhvfWQH54D6wr9fZ3dz4CkGAzIG5AqcDmqqqP/FlznZAsaUoHpPZAv7Y5KjA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761771979; c=relaxed/simple; bh=Np5CMFbWfUmbU6MayjZ40pxjcZnyi9oeks/j+smFIbo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UxfMikhN5zJ+5bkMPaocslvTYFDqsxvdlbx3EeboTb6iSe3WUc8qSXq4p7WftutoIdPEERu0Ytm1FAVKYfUAVaFrZPqdXV+SunaDdQqd6RYlqaVFJeYXDGt45G8H2G0CG+ThiSNTA5izwhLUoqhtomlkwTTK2BLTVkAIhDbB9aI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=OkNFSSjW; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="OkNFSSjW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761771978; x=1793307978; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Np5CMFbWfUmbU6MayjZ40pxjcZnyi9oeks/j+smFIbo=; b=OkNFSSjWU5/kAdKnvf6VcexPVvKd8c1x8IaYy65x74JcKpAu/c0LHtGU jOAZ+uWlJsyksipomavlXUlGXByn3NGtakCEKojIbBDKBoewJSuiap4KW MWzzSMNjdSo6aAN9xi1oyqP5LK+Lmglqta6Db05npUsgmZz6LtEHcdu5Q QUawcDnv8hultVtZuwh/WJMab8n+q11zvsrB7IO8bLOmyV8ZyCwQPBhy3 aNSFFPwTXlJNga5E5oCN+E9mV5ERT/c84DWgKnTXXzahCAxvzEc9TowQr p2gsdaXkKCD4k7g2bDsrbl14wlcfsN1B/+iTL/ojCi7WOx842AHbFilZH Q==; X-CSE-ConnectionGUID: 9prTzSlOS1+C5aakqn1MAw== X-CSE-MsgGUID: 0yND17ZeSRC2/VOi+EPefQ== X-IronPort-AV: E=McAfee;i="6800,10657,11597"; a="64002745" X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="64002745" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2025 14:06:16 -0700 X-CSE-ConnectionGUID: hzvYjJXbTG6vTHQfvsUQgA== X-CSE-MsgGUID: cmBIxFr2RDCHUhRKjX2Oog== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,265,1754982000"; d="scan'208";a="216432021" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa002.jf.intel.com with ESMTP; 29 Oct 2025 14:06:16 -0700 From: Sohil Mehta To: x86@kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: Jonathan Corbet , "H . Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Ard Biesheuvel , "Kirill A . Shutemov" , Sohil Mehta , Xin Li , David Woodhouse , Sean Christopherson , Rick Edgecombe , Vegard Nossum , Andrew Cooper , Randy Dunlap , Geert Uytterhoeven , Kees Cook , Tony Luck , Alexander Shishkin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org Subject: [PATCH v11 9/9] x86/cpu: Enable LASS by default during CPU initialization Date: Wed, 29 Oct 2025 14:03:10 -0700 Message-ID: <20251029210310.1155449-10-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251029210310.1155449-1-sohil.mehta@intel.com> References: <20251029210310.1155449-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Linear Address Space Separation (LASS) mitigates a class of side-channel attacks that rely on speculative access across the user/kernel boundary. Enable LASS by default if the platform supports it. While at it, remove the comment above the SMAP/SMEP/UMIP/LASS setup instead of updating it, as the whole sequence is quite self-explanatory. The legacy vsyscall page is mapped at 0xffffffffff60?000. Prior to LASS, vsyscall page accesses would always generate a #PF. The kernel emulates the accesses in the #PF handler and returns the appropriate values to userspace. With LASS, these accesses are intercepted before the paging structures are traversed triggering a #GP instead of a #PF. To avoid breaking user applications, equivalent emulation support is required in the #GP handler. However, the #GP provides limited error information compared to the #PF, making the emulation more complex. For now, keep it simple and disable LASS if vsyscall emulation is compiled in. This restricts LASS usability to newer environments where legacy vsyscalls are absolutely not needed. In future, LASS support can be expanded by enhancing the #GP handler. Signed-off-by: Sohil Mehta Reviewed-by: Dave Hansen --- v11: - Disable LASS if vsyscall emulation support is compiled in. - Drop Rick's review tag because of the new changes. v10 - No change. --- arch/x86/kernel/cpu/common.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index c7d3512914ca..71e89859dfb4 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -401,6 +401,25 @@ 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)) { + /* + * Legacy vsyscall page access causes a #GP when LASS is + * active. However, vsyscall emulation isn't supported + * with #GP. To avoid breaking userspace, disable LASS + * if the emulation code is compiled in. + */ + if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION)) { + pr_info_once("x86/cpu: Disabling LASS due to CONFIG_X86_VSYSCALL_EMULAT= ION=3Dy\n"); + setup_clear_cpu_cap(X86_FEATURE_LASS); + return; + } + + 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; @@ -2011,10 +2030,10 @@ static void identify_cpu(struct cpuinfo_x86 *c) /* Disable the PN if appropriate */ squash_the_stupid_serial_number(c); =20 - /* Set up SMEP/SMAP/UMIP */ setup_smep(c); setup_smap(c); setup_umip(c); + setup_lass(c); =20 /* Enable FSGSBASE instructions if available. */ if (cpu_has(c, X86_FEATURE_FSGSBASE)) { --=20 2.43.0