From nobody Thu Apr 9 09:47:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (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 696571DC9B3; Mon, 9 Mar 2026 18:12:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079961; cv=none; b=pcrRyFSxU1h8JnCwjUuBfYhHEeGHxtkJkeOSe2ZbYMvxhrRYn0ykwbe+cfFK6ylqQrSQIiPMPxE3KoL0XcNqO1xVqyqeu+q4DSQFeCd84MrBRpqmsFR7aDGEaYC8m/iWdUKbidASm0pfujQT4EaMsxKwWvXsVrUyZGw4xp0NyfI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079961; c=relaxed/simple; bh=SMQ9y/Ah5jn6S89OyyLNHHww/Di58CFAF1TDAO2VSoU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oLVqtZNd6Da8YMRQS3jmGm9/KrkKDsSZZPfBxR9BtlzX2JZsYSPlFxuHk31bAr1FpEVvRLcMKPAeisOIGgb4IGrtmi21+XX+2nGyiVwMgoKYwto+stYdIANHCQp9Ne96Wma4IZaoqCYfk8TjPt1hxgx/m8nZSdpiibT37pbPnfM= 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=U4QdY+bR; arc=none smtp.client-ip=198.175.65.21 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="U4QdY+bR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773079961; x=1804615961; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SMQ9y/Ah5jn6S89OyyLNHHww/Di58CFAF1TDAO2VSoU=; b=U4QdY+bRNTzuCNLm1bDAu3jWfB9+C72egnxiW3H8MIlvE6Nzg/Bd/1ML yrUmg35QJu9vnjtPDGpmvnQNSlbAOeB+ZSbi5yP/wg8tUOc8UMwG2colD wei7Qh2y2RPvvvCJilImlbFT25MvDQOJQ4njH91ApuooquAMYyOsdqVbE /oQqYV+O3AsLD1pA7B+P3Ja2P4lpI4ifqz5kO5qa6WXRyy7No5F/8udt7 aw42uBgzpWZNN4aNKYfEdahmLJCU/DiSgvJL+QRI9HApaJXem6oMX173p Qh4O4uzksYIm8nCQgadcgrH8+iA4NuIVXyChVIvEMjMigpqUJyaK6TfIB Q==; X-CSE-ConnectionGUID: /jxiYesmSfieTDe7MGeZ1g== X-CSE-MsgGUID: PIrEJpONTW6LVhwlbuo0iQ== X-IronPort-AV: E=McAfee;i="6800,10657,11724"; a="73992027" X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="73992027" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2026 11:12:39 -0700 X-CSE-ConnectionGUID: NcA/pOJAR3SnisfrCv/qJQ== X-CSE-MsgGUID: ogReXCc9SECCh3N2YXWxgw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="224774442" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa005.jf.intel.com with ESMTP; 09 Mar 2026 11:12:38 -0700 From: Sohil Mehta To: Dave Hansen , x86@kernel.org, Andy Lutomirski , Borislav Petkov Cc: Jonathan Corbet , Shuah Khan , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Peter Zijlstra , Sohil Mehta , Kiryl Shutsemau , Brendan Jackman , Sean Christopherson , Nam Cao , Cedric Xing , Rick Edgecombe , Andrew Cooper , Tony Luck , Alexander Shishkin , Maciej Wieczor-Retman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 1/5] x86/vsyscall: Reorganize the page fault emulation code Date: Mon, 9 Mar 2026 11:10:25 -0700 Message-ID: <20260309181029.398498-2-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309181029.398498-1-sohil.mehta@intel.com> References: <20260309181029.398498-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, vsyscall page accesses will cause a #GP instead of a #PF. Separate out the core vsyscall emulation code from the #PF specific handling in preparation for the upcoming #GP emulation. No functional change intended. Signed-off-by: Sohil Mehta Acked-by: Dave Hansen Reviewed-by: H. Peter Anvin (Intel) Tested-by: Maciej Wieczor-Retman --- v3: - Minor change to keep the data access return code flow the same as the original. - Pick up review and tested-by tags. v2: - No change --- arch/x86/entry/vsyscall/vsyscall_64.c | 66 ++++++++++++++------------- arch/x86/include/asm/vsyscall.h | 7 ++- arch/x86/mm/fault.c | 2 +- 3 files changed, 39 insertions(+), 36 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index 4bd1e271bb22..398b1ed16f1e 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -111,43 +111,13 @@ static bool write_ok_or_segv(unsigned long ptr, size_= t size) } } =20 -bool emulate_vsyscall(unsigned long error_code, - struct pt_regs *regs, unsigned long address) +static bool __emulate_vsyscall(struct pt_regs *regs, unsigned long address) { unsigned long caller; int vsyscall_nr, syscall_nr, tmp; long ret; unsigned long orig_dx; =20 - /* Write faults or kernel-privilege faults never get fixed up. */ - if ((error_code & (X86_PF_WRITE | X86_PF_USER)) !=3D X86_PF_USER) - return false; - - /* - * Assume that faults at regs->ip are because of an - * instruction fetch. Return early and avoid - * emulation for faults during data accesses: - */ - if (address !=3D regs->ip) { - /* Failed vsyscall read */ - if (vsyscall_mode =3D=3D EMULATE) - return false; - - /* - * User code tried and failed to read the vsyscall page. - */ - warn_bad_vsyscall(KERN_INFO, regs, "vsyscall read attempt denied -- look= up the vsyscall kernel parameter if you need a workaround"); - return false; - } - - /* - * X86_PF_INSTR is only set when NX is supported. When - * available, use it to double-check that the emulation code - * is only being used for instruction fetches: - */ - if (cpu_feature_enabled(X86_FEATURE_NX)) - WARN_ON_ONCE(!(error_code & X86_PF_INSTR)); - /* * No point in checking CS -- the only way to get here is a user mode * trap to a high address, which means that we're in 64-bit user code. @@ -280,6 +250,40 @@ bool emulate_vsyscall(unsigned long error_code, return true; } =20 +bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, + unsigned long address) +{ + /* Write faults or kernel-privilege faults never get fixed up. */ + if ((error_code & (X86_PF_WRITE | X86_PF_USER)) !=3D X86_PF_USER) + return false; + + /* + * Assume that faults at regs->ip are because of an instruction + * fetch. Return early and avoid emulation for faults during + * data accesses: + */ + if (address !=3D regs->ip) { + /* 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 paramet= er if you need a workaround"); + return false; + } + + /* + * X86_PF_INSTR is only set when NX is supported. When + * available, use it to double-check that the emulation code + * is only being used for instruction fetches: + */ + if (cpu_feature_enabled(X86_FEATURE_NX)) + WARN_ON_ONCE(!(error_code & X86_PF_INSTR)); + + return __emulate_vsyscall(regs, address); +} + /* * A pseudo VMA to allow ptrace access for the vsyscall page. This only * covers the 64bit vsyscall page now. 32bit has a real VMA now and does diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscal= l.h index 472f0263dbc6..f34902364972 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -14,12 +14,11 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root); * Called on instruction fetch fault in vsyscall page. * Returns true if handled. */ -extern bool emulate_vsyscall(unsigned long error_code, - struct pt_regs *regs, unsigned long address); +bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, u= nsigned long address); #else static inline void map_vsyscall(void) {} -static inline bool emulate_vsyscall(unsigned long error_code, - struct pt_regs *regs, unsigned long address) +static inline bool emulate_vsyscall_pf(unsigned long error_code, + struct pt_regs *regs, unsigned long address) { return false; } diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index b83a06739b51..f0e77e084482 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1314,7 +1314,7 @@ void do_user_addr_fault(struct pt_regs *regs, * to consider the PF_PK bit. */ if (is_vsyscall_vaddr(address)) { - if (emulate_vsyscall(error_code, regs, address)) + if (emulate_vsyscall_pf(error_code, regs, address)) return; } #endif --=20 2.43.0 From nobody Thu Apr 9 09:47:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (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 119292D0C92; Mon, 9 Mar 2026 18:12:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079962; cv=none; b=kjcLu1xcWH0SwvsA2lIoJdYVQV5lm9I/fSgQr+mtNA1xSXyv5rVQW7kS2aPukTVPTp1k5+yPC3Un2r7Fzqw+q5hs6scZheCVOvZaaO+gYI+GbWNQ2CeiOHvE0bnwL4eOWatq04yEGrsQYb2zGJ/dFx1zC5pr/qjyHPh+gmP/lW0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079962; c=relaxed/simple; bh=vv6YWxEJ4PIxGMLDlwY2P30jDjpKSWyC+WmfT7BLFCw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DpgTJ54l2ZsTGIZkG8VifPMopXCYrDrDYTPOgoEHYDQXxYq2rI9NRH4uPxFg8D70eNX3cR12gBWkhusuGtnCXXPIAOirH3RUNNB2eMIXFLIFHe6usjFiymKmZusmQRUAsaoEVIGVxd2xWq7s9YnTOGM8w1r2eaDrs48K8//yNt4= 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=ijXwK5h4; arc=none smtp.client-ip=198.175.65.21 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="ijXwK5h4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773079961; x=1804615961; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vv6YWxEJ4PIxGMLDlwY2P30jDjpKSWyC+WmfT7BLFCw=; b=ijXwK5h4TbRvdVbJXw7irJhTBeVYrr1IWDcsgQcE93gOIBJWZfsSmWoQ YJ/rxsgmjio7mdWwWjmkTIu8iNOooCJvLWaP2yhRGYZwyRj0g8Yg4qlwP yfSaDhTmzpScjs9/zWU50AZTKI4COx+snaVJG2Y5baf3GTQaQ1ngN2yQG /swy7xEeI2zIB5xLl3PR/qv+FseGByEOH+/ExbNbsIK4GD51yUeGuCMZS KQKp1yeF6OLAEPQXxa2lFMqaTizx39w10BHCsKlC2sy2apEegbyDGTuSd 3gnO6gy8G/c5n08WJidK7VZxl3htXt2GFAnylN6vzcrz8evZP5AzEEERG A==; X-CSE-ConnectionGUID: xrIJwjtiSRarax5Kj2BgDQ== X-CSE-MsgGUID: PI0LjpsRS9ChaRmB/eb6TA== X-IronPort-AV: E=McAfee;i="6800,10657,11724"; a="73992042" X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="73992042" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2026 11:12:40 -0700 X-CSE-ConnectionGUID: E8GbfMlZQV2QL37I3ZPTjA== X-CSE-MsgGUID: FbqQIrf1TAConcX/EF2ILw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="224774455" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa005.jf.intel.com with ESMTP; 09 Mar 2026 11:12:39 -0700 From: Sohil Mehta To: Dave Hansen , x86@kernel.org, Andy Lutomirski , Borislav Petkov Cc: Jonathan Corbet , Shuah Khan , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Peter Zijlstra , Sohil Mehta , Kiryl Shutsemau , Brendan Jackman , Sean Christopherson , Nam Cao , Cedric Xing , Rick Edgecombe , Andrew Cooper , Tony Luck , Alexander Shishkin , Maciej Wieczor-Retman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 2/5] x86/traps: Consolidate user fixups in the #GP handler Date: Mon, 9 Mar 2026 11:10:26 -0700 Message-ID: <20260309181029.398498-3-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309181029.398498-1-sohil.mehta@intel.com> References: <20260309181029.398498-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Move the UMIP exception fixup under the common "if (user_mode(regs))" condition where the rest of user mode fixups reside. Also, move the UMIP feature check into its fixup function to keep the calling code consistent and clean. No functional change intended. Suggested-by: Dave Hansen Signed-off-by: Sohil Mehta Acked-by: Dave Hansen Reviewed-by: H. Peter Anvin (Intel) Tested-by: Maciej Wieczor-Retman --- v3: - Pickup review and tested-by tags. v2: - No change --- arch/x86/kernel/traps.c | 8 +++----- arch/x86/kernel/umip.c | 3 +++ 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 4dbff8ef9b1c..614a281bd419 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -921,11 +921,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); @@ -940,6 +935,9 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) if (fixup_vdso_exception(regs, X86_TRAP_GP, error_code, 0)) goto exit; =20 + if (fixup_umip_exception(regs)) + goto exit; + gp_user_force_sig_segv(regs, X86_TRAP_GP, error_code, desc); goto exit; } diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c index d432f3824f0c..3ce99cbcf187 100644 --- a/arch/x86/kernel/umip.c +++ b/arch/x86/kernel/umip.c @@ -354,6 +354,9 @@ bool fixup_umip_exception(struct pt_regs *regs) void __user *uaddr; struct insn insn; =20 + if (!cpu_feature_enabled(X86_FEATURE_UMIP)) + return false; + if (!regs) return false; =20 --=20 2.43.0 From nobody Thu Apr 9 09:47:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (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 B3A8D2FD695; Mon, 9 Mar 2026 18:12:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079963; cv=none; b=NdxDokDIGdhuZhtURILk12XljxiWPTEGIE0uVwHjKKSNuyVCi4Kl/3UMPnXKdB1+rRonyJRI5oPiMDXaCtzKrYdiezRfbzs1wb34FcInKSGd/qOesXk59qkuajSrYQGmjjmFpEAUspQ3Yuny997TaRicgQKObh7vyuyXyEltf3s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079963; c=relaxed/simple; bh=n9R5ZYXCcp7UGrAzZghqZU527LLKI9taOUYp1CkiIbE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XQy/mPCOYdb6hmR6iEFx7UiyCE0Mx1QOVZB6MsBsjkYk/5x2U7apUQP9FWvHOAbLEAv7Lr8t2ivHhKIp5AIpENBB5eBGSDnrfvMoC/tqu826YZEOdwdxHtWfNOJZkCBeu0/4X+C+sfDmwQQ7Rg6Vhtims6aUAYBb29kEogTCFAI= 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=cZwfoVRp; arc=none smtp.client-ip=198.175.65.21 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="cZwfoVRp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773079962; x=1804615962; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=n9R5ZYXCcp7UGrAzZghqZU527LLKI9taOUYp1CkiIbE=; b=cZwfoVRpyAdwvUn7LLouQmcE2BQtz5fv4JHRy0r2z15rV6YpcbI/2zJC xB3mLqOg6bTAPuykojDs9KQDRPG9HQm0DHoxDXHoJcPsUCIQYyW+ld/jw FYbYG9T5ExSL1EDZobtEkj82B3zvY6GT89eBkAwG2/85510sDc40mSAln HbfzGY5fDmft6TQwLpzvp5sLXEE/M4swRcGjJsGxYMYdQtJh35iyVDYWN gp9ITkhr9S9aoMaVtGfzwpCzprieqWcOBlwjoJXxZYIr4XPiB9ptOAsq+ 4003+zCt//FRVOa7j9PvgLEb0id/y1U2NpkLN5sRAt0dnFt4h7b/137ML A==; X-CSE-ConnectionGUID: jsoTBEP/Qs6Q1CWzefVlJA== X-CSE-MsgGUID: ONlj6MAsRK6xM5ZBY4kumg== X-IronPort-AV: E=McAfee;i="6800,10657,11724"; a="73992057" X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="73992057" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2026 11:12:41 -0700 X-CSE-ConnectionGUID: kkmcXaibRAC2NyAnVHV6tQ== X-CSE-MsgGUID: Cf+YSycvSi+YaMunfPh5iA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="224774464" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa005.jf.intel.com with ESMTP; 09 Mar 2026 11:12:41 -0700 From: Sohil Mehta To: Dave Hansen , x86@kernel.org, Andy Lutomirski , Borislav Petkov Cc: Jonathan Corbet , Shuah Khan , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Peter Zijlstra , Sohil Mehta , Kiryl Shutsemau , Brendan Jackman , Sean Christopherson , Nam Cao , Cedric Xing , Rick Edgecombe , Andrew Cooper , Tony Luck , Alexander Shishkin , Maciej Wieczor-Retman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 3/5] x86/vsyscall: Restore vsyscall=xonly mode under LASS Date: Mon, 9 Mar 2026 11:10:27 -0700 Message-ID: <20260309181029.398498-4-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309181029.398498-1-sohil.mehta@intel.com> References: <20260309181029.398498-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" Background =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The vsyscall page is located in the high/kernel part of the address space. Prior to LASS, a vsyscall page access from userspace would always generate a #PF. The kernel emulates the accesses in the #PF handler and returns the appropriate values to userspace. Vsyscall emulation has two modes of operation, specified by the vsyscall=3D{xonly, emulate} kernel command line option. The vsyscall page behaves as execute-only in XONLY mode or read-execute in EMULATE mode. XONLY mode is the default and the only one expected to be commonly used. The EMULATE mode has been deprecated since 2022 and is considered insecure. With LASS, a vsyscall page access triggers a #GP instead of a #PF. Currently, LASS is only enabled when all vsyscall modes are disabled. LASS with XONLY mode =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Now add support for LASS specifically with XONLY vsyscall emulation. For XONLY mode, all that is needed is the faulting RIP, which is trivially available regardless of the type of fault. Reuse the #PF emulation code during the #GP when the fault address points to the vsyscall page. As multiple fault handlers will now be using the emulation code, add a sanity check to ensure that the fault truly happened in 64-bit user mode. LASS with EMULATE mode =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Supporting vsyscall=3Demulate with LASS is much harder because the #GP doesn't provide enough error information (such as PFEC and CR2 as in case of a #PF). So, complex instruction decoding would be required to emulate this mode in the #GP handler. This isn't worth the effort as remaining users of EMULATE mode can be reasonably assumed to be niche users, who are already trading off security for compatibility. LASS and vsyscall=3Demulate will be kept mutually exclusive for simplicity. Signed-off-by: Sohil Mehta Reviewed-by: H. Peter Anvin (Intel) Tested-by: Maciej Wieczor-Retman --- v3: - Pick up review and tested-by tags. v2: - Rewrote the commit message --- arch/x86/entry/vsyscall/vsyscall_64.c | 22 +++++++++++++++++----- arch/x86/include/asm/vsyscall.h | 6 ++++++ arch/x86/kernel/traps.c | 4 ++++ 3 files changed, 27 insertions(+), 5 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index 398b1ed16f1e..e740f3b42278 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 @@ -118,10 +118,9 @@ static bool __emulate_vsyscall(struct pt_regs *regs, u= nsigned long address) long ret; unsigned long orig_dx; =20 - /* - * 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. - */ + /* Confirm that the fault happened in 64-bit user mode */ + if (!user_64bit_mode(regs)) + return false; =20 if (vsyscall_mode =3D=3D NONE) { warn_bad_vsyscall(KERN_INFO, regs, @@ -284,6 +283,19 @@ bool emulate_vsyscall_pf(unsigned long error_code, str= uct pt_regs *regs, return __emulate_vsyscall(regs, address); } =20 +bool emulate_vsyscall_gp(struct pt_regs *regs) +{ + /* Without LASS, vsyscall accesses are expected to generate a #PF */ + if (!cpu_feature_enabled(X86_FEATURE_LASS)) + return false; + + /* Emulate only if the RIP points to the vsyscall address */ + if (!is_vsyscall_vaddr(regs->ip)) + return false; + + return __emulate_vsyscall(regs, regs->ip); +} + /* * A pseudo VMA to allow ptrace access for the vsyscall page. This only * covers the 64bit vsyscall page now. 32bit has a real VMA now and does diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscal= l.h index f34902364972..538053b1656a 100644 --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -15,6 +15,7 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root); * Returns true if handled. */ bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, u= nsigned long address); +bool emulate_vsyscall_gp(struct pt_regs *regs); #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall_pf(unsigned long error_code, @@ -22,6 +23,11 @@ static inline bool emulate_vsyscall_pf(unsigned long err= or_code, { return false; } + +static inline bool emulate_vsyscall_gp(struct pt_regs *regs) +{ + return false; +} #endif =20 /* diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 614a281bd419..0ca3912ecb7f 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -70,6 +70,7 @@ #include #include #include +#include =20 #ifdef CONFIG_X86_64 #include @@ -938,6 +939,9 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) if (fixup_umip_exception(regs)) goto exit; =20 + if (emulate_vsyscall_gp(regs)) + goto exit; + gp_user_force_sig_segv(regs, X86_TRAP_GP, error_code, desc); goto exit; } --=20 2.43.0 From nobody Thu Apr 9 09:47:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (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 EE6CB311950; Mon, 9 Mar 2026 18:12:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079964; cv=none; b=WvDgY657CD0/4n8BNbKhkx6qjWxc/aUS5wfws7/gcygoqSBB+iFOyH8iednwgS38UEAjPFZewoUtk3RvXBcfWC1BuhhlluDVrp559aHTsubJBUUl3oi7Oivskb+dzn+8p/YphNtXWk2x0ORupwI9OuvyO0WyyxwZAs1/BYMmDPU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079964; c=relaxed/simple; bh=WaltZvFYX7Rj0hNcyUoNBRNQ8wFZNOgcYwUjIIwEWjk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I7aXcDElPFvlmDLLadUlkc/L/UUprMbbWoVst7V/sDstw1YTgFNX7FgxIZgrY9YxM3cWeFuSYawjUzORVmGSAWChsWo2tEWP3R4tHbNnLeeWDqoj1dhPoBReizrE5q2mHCfZQWIgAH+L7CQCvm85+H9W2tOxPNRxDU0fiJOhmtc= 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=V5aliJoO; arc=none smtp.client-ip=198.175.65.21 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="V5aliJoO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773079963; x=1804615963; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=WaltZvFYX7Rj0hNcyUoNBRNQ8wFZNOgcYwUjIIwEWjk=; b=V5aliJoO+BoVRZdyqd0vw8PKjZ5Mhfbu9HgRctEa62hzDpWY/EacHOYs l85KFGqyLPRJ1MOibzb1WYr50MNTe87W90ALBvIxWBKP5b6ZhrVTR0lR1 Yle2yUW1Cg7X8Lbm0/l9GP9OqhDeJ7pM592mWubHbwJlXPvIfYT296kQC hB4r9CND00zzcffspUj2Fb6Md0uTHg1Spn1RqmP5csTDiZnhS79qhZMXG fAtLflthoYEvZ9PYFgV9R4RMlSq4FPXNZkU3np0ODOIzhBqedCR4ilXOq rqWcVMR4kIibRuWyvRDnSimnK9M79UmI12Fvrqy8yw5ltIP8cpaWNK7u6 Q==; X-CSE-ConnectionGUID: EltfuFdVRVGEaYZ9663wwA== X-CSE-MsgGUID: cXavrYMrT8+ZXgjH7uIDGg== X-IronPort-AV: E=McAfee;i="6800,10657,11724"; a="73992075" X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="73992075" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2026 11:12:43 -0700 X-CSE-ConnectionGUID: KAt9/CRcTMavTlaXT6u6gw== X-CSE-MsgGUID: FhoAWZWTRKGfNAbEa4MVWQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="224774476" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa005.jf.intel.com with ESMTP; 09 Mar 2026 11:12:42 -0700 From: Sohil Mehta To: Dave Hansen , x86@kernel.org, Andy Lutomirski , Borislav Petkov Cc: Jonathan Corbet , Shuah Khan , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Peter Zijlstra , Sohil Mehta , Kiryl Shutsemau , Brendan Jackman , Sean Christopherson , Nam Cao , Cedric Xing , Rick Edgecombe , Andrew Cooper , Tony Luck , Alexander Shishkin , Maciej Wieczor-Retman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 4/5] x86/vsyscall: Disable LASS if vsyscall mode is set to EMULATE Date: Mon, 9 Mar 2026 11:10:28 -0700 Message-ID: <20260309181029.398498-5-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309181029.398498-1-sohil.mehta@intel.com> References: <20260309181029.398498-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The EMULATE mode of vsyscall maps the vsyscall page with a high kernel address directly into user address space. Reading the vsyscall page in EMULATE mode would cause LASS to trigger a #GP. Fixing the LASS violation in EMULATE mode would require complex instruction decoding because the resulting #GP does include the necessary error information, and the vsyscall address is not readily available in the RIP. The EMULATE mode has been deprecated since 2022 and can only be enabled using the command line parameter vsyscall=3Demulate. See commit bf00745e7791 ("x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE") for details. At this point, no one is expected to be using this insecure mode. The rare usages that need it obviously do not care about security. Disable LASS when EMULATE mode is requested to avoid breaking legacy user software. Also, update the vsyscall documentation to reflect this. LASS will only be supported if vsyscall mode is set to XONLY (default) or NONE. Signed-off-by: Sohil Mehta Reviewed-by: Rick Edgecombe Reviewed-by: Dave Hansen Reviewed-by: H. Peter Anvin (Intel) Tested-by: Maciej Wieczor-Retman --- Eventually, the plan is to get rid of the EMULATE mode altogether. Linus and AndyL seem to be okay with such a change. However, those changes are beyond the scope of this series. v3: - Pick up review and tested-by tags. v2: - Picked up Dave's review tag - Removed unnecessary CR4 clearing during vsyscall_setup(). CR4.LASS is enabled much later via a late_initcall(). --- Documentation/admin-guide/kernel-parameters.txt | 4 +++- arch/x86/entry/vsyscall/vsyscall_64.c | 5 +++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio= n/admin-guide/kernel-parameters.txt index cb850e5290c2..64df2c52b2e5 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -8376,7 +8376,9 @@ Kernel parameters =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 e740f3b42278..ea36de9fa864 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -62,6 +62,11 @@ static int __init vsyscall_setup(char *str) else return -EINVAL; =20 + if (cpu_feature_enabled(X86_FEATURE_LASS) && vsyscall_mode =3D=3D EMULAT= E) { + setup_clear_cpu_cap(X86_FEATURE_LASS); + pr_warn_once("x86/cpu: Disabling LASS due to vsyscall=3Demulate\n"); + } + return 0; } =20 --=20 2.43.0 From nobody Thu Apr 9 09:47:30 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (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 283833382FE; Mon, 9 Mar 2026 18:12:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079965; cv=none; b=SWjSC/3KOL1hRwHRNyF4JSONqrRS5jKNwOulOWuBI4Fyc1lU28tL5hh0QbGotPYACGCM7zH3+ez6EC6FcPw+Zrw9e6N6DGXxspqmEye/9i3aNFAuglUEP5wIdcvNUcrpRyyDGeoPx/TMw6NUPWpIP1xftZ3+iBmtq9fx8uUUE4s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773079965; c=relaxed/simple; bh=1qzEqFPdZuX9j2z6MnjXL40+sdQNv2B1yHC6um5bTq0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dTl1NWnXKR+ghHDDZAt/8vBGjGUtpx+4xW1jAhUxFOMjns0ARmPiQYnB3lLQyRiiEUgwwxpOU9v9M3wiIy0/Pkbl9IhqeiuQ2QJWKIA9ojBx066/WAbqRbg2mDY4nEeTSiKL1yu5bCW02QpfNCvpE5lyjeC1o0e0Lb712233MOM= 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=HQhRLy78; arc=none smtp.client-ip=198.175.65.21 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="HQhRLy78" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773079964; x=1804615964; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=1qzEqFPdZuX9j2z6MnjXL40+sdQNv2B1yHC6um5bTq0=; b=HQhRLy78FWxfoXyMpDe7xjfxiav4dTTZjgo7iCbe2NsZRXDrjV5S1owC kEMKDuhfC5h1LTna09yj/prmfWJY3UDec3hJetzxDJH7TcQ8dtRz6raJX ShUYSLy3tuFd01RAjtz+YabNstV0OExoIRCeG7820OCuMEZwm4lPos8nm NzNF4TWWhDjmhWvtBbLiiTJU4KjQ8qCaqKIX/KOEK4i6feyEI9PvHQ/ue iMz3V8oiilZDOnTMNo4zrH9cEgke1V/tVTJEp6am/yRd5mYZmCFM5/5Qp eeL1poCYReJV5U8VspW2iroLvkJbiY6CuhwnqYTe8dy8bqZh2rI4hYjZn Q==; X-CSE-ConnectionGUID: 9U2c3t/YTc6DhJ1tC4oObA== X-CSE-MsgGUID: 3ml5G/RGRbazBxX+eWQMsg== X-IronPort-AV: E=McAfee;i="6800,10657,11724"; a="73992089" X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="73992089" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2026 11:12:44 -0700 X-CSE-ConnectionGUID: PG4ZSg2IQPCV+zKGdBk47A== X-CSE-MsgGUID: LO2whBOJS7WCRSTi7miORg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,109,1770624000"; d="scan'208";a="224774483" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa005.jf.intel.com with ESMTP; 09 Mar 2026 11:12:43 -0700 From: Sohil Mehta To: Dave Hansen , x86@kernel.org, Andy Lutomirski , Borislav Petkov Cc: Jonathan Corbet , Shuah Khan , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Peter Zijlstra , Sohil Mehta , Kiryl Shutsemau , Brendan Jackman , Sean Christopherson , Nam Cao , Cedric Xing , Rick Edgecombe , Andrew Cooper , Tony Luck , Alexander Shishkin , Maciej Wieczor-Retman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 5/5] x86/cpu: Remove LASS restriction on vsyscall emulation Date: Mon, 9 Mar 2026 11:10:29 -0700 Message-ID: <20260309181029.398498-6-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309181029.398498-1-sohil.mehta@intel.com> References: <20260309181029.398498-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" Vsyscall emulation has two modes of operation: XONLY and EMULATE. The default XONLY mode is now supported with a LASS-triggered #GP. OTOH, LASS is disabled if someone requests the deprecated EMULATE mode via the vsyscall=3Demulate command line option. So, remove the restriction on LASS when the overall vsyscall emulation support is compiled in. As a result, there is no need for setup_lass() anymore. LASS is enabled by default through a late_initcall(). Signed-off-by: Sohil Mehta Reviewed-by: Dave Hansen Reviewed-by: H. Peter Anvin (Intel) Tested-by: Maciej Wieczor-Retman --- v3: - Pick up review and tested-by tags. v2: - Picked up Dave's review tag - Improve commit message --- arch/x86/kernel/cpu/common.c | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 3557f0e6b3aa..02472fc763d9 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -406,20 +406,6 @@ 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)) - return; - - /* - * Legacy vsyscall page access causes a #GP when LASS is active. - * Disable LASS because the #GP handler doesn't support vsyscall - * emulation. - */ - if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION)) - setup_clear_cpu_cap(X86_FEATURE_LASS); -} - static int enable_lass(unsigned int cpu) { cr4_set_bits(X86_CR4_LASS); @@ -2061,7 +2047,6 @@ static void identify_cpu(struct cpuinfo_x86 *c) 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