From nobody Sun Apr 5 13:04:57 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 E163A1D5CD9; Thu, 19 Feb 2026 23:38:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544291; cv=none; b=VpTvMpc/+bZMZ5Wa+eOkt6HeX5GUz4BzHuVE3Y8PfIwZhk9jNvTwaqWYZhBK7FfCX2FGXlaPPaclgXUO8U53B8WY8k+xU/9EnH3Np+lYc6L8IY43XQ4I06GWi2wKPqzOyQpHx/CYl3y9qAE73TajlFyMs7sp1rXfWMKf6yhKYq0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544291; c=relaxed/simple; bh=sUnxRmePbDNVJguI5BQGGnhht0CrViyCGX1gaDyH53s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Si6Yxm1/NUzzjVD9TgvRZ3bszSiRDQ7afP0SQGKcrOycOMwWMdpQcEmw66SBNexCakE03PmugKK7AGbBuobPdRCkR4goyVEornD5OMpKeefc0VkrDjzvNzpfQvv6UXMYCqlUsrwW7qpvY3RwC4rpvL0cXGJlDeuItod401IuTOg= 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=LBHmx0q+; arc=none smtp.client-ip=198.175.65.18 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="LBHmx0q+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771544290; x=1803080290; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=sUnxRmePbDNVJguI5BQGGnhht0CrViyCGX1gaDyH53s=; b=LBHmx0q+xZyN8Jl/Fj5YQfQ8YZBLL2SRccWP6cQHma3tLGy8SiPmkLOf csvvGkM9TMiusDdhpBJLBaaP4jzUou3G2LDnXCOofyOqGQNP11pevvHv7 njVKDUvJV/AuVi81HeTZR5aYuIsui22PBhbUEKN7moyliQf0/P7TttMHl ecH64Ge8JZF8I7OzL8VinJ/8QVRgfAFiYmdNZqQSBXY7KVgUH6LpKl/73 ATWyTPo8VjNrGn+TKwPzfXc43xYLzvPQoDrU+lHItx2/ncCSR5yotmNb+ H6k3oRUu6g82DcE8dLeoCzKMnBA4lie97ZRlp2VBQLxvcd0upWavg0mdw Q==; X-CSE-ConnectionGUID: Y2lYJ0sTSSGg9FCNzAbl4A== X-CSE-MsgGUID: 0FDC/ULdTiel6L8YIFPq5A== X-IronPort-AV: E=McAfee;i="6800,10657,11706"; a="72685703" X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="72685703" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2026 15:38:08 -0800 X-CSE-ConnectionGUID: fxDMCSdnSIih1ObLWm+NEQ== X-CSE-MsgGUID: hcv8FBQxQi+Jl+MEQEGLBw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="214805177" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa007.jf.intel.com with ESMTP; 19 Feb 2026 15:38:08 -0800 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 1/5] x86/vsyscall: Reorganize the page fault emulation code Date: Thu, 19 Feb 2026 15:35:56 -0800 Message-ID: <20260219233600.154313-2-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260219233600.154313-1-sohil.mehta@intel.com> References: <20260219233600.154313-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 --- arch/x86/entry/vsyscall/vsyscall_64.c | 64 ++++++++++++++------------- arch/x86/include/asm/vsyscall.h | 7 ++- arch/x86/mm/fault.c | 2 +- 3 files changed, 37 insertions(+), 36 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index 4bd1e271bb22..5c6559c37c5b 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,38 @@ bool emulate_vsyscall(unsigned long error_code, return true; } =20 +bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, + unsigned long address) +{ + /* Write faults or kernel-privilege faults never get fixed up. */ + if ((error_code & (X86_PF_WRITE | X86_PF_USER)) !=3D X86_PF_USER) + return false; + + /* + * Assume that faults at regs->ip are because of an instruction + * fetch. Return early and avoid emulation for faults during + * data accesses: + */ + if (address !=3D regs->ip) { + /* User code tried and failed to read the vsyscall page. */ + if (vsyscall_mode !=3D EMULATE) + warn_bad_vsyscall(KERN_INFO, regs, + "vsyscall read attempt denied -- look up the vsyscall kernel parame= ter 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 Sun Apr 5 13:04:57 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 A64D63090F1; Thu, 19 Feb 2026 23:38:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544291; cv=none; b=rJfp2ODOSN8CCtdcK7DKgVsFiZgHP+kGO0vdrRy4r8fRInVfVnapVEPEIrLyog7NgxLNXR+PxESyH3o+jLlsZwe/6ZqNJF4dgqExA3P9J1xWJWU1onIe6ta9mxa6G2LGNd0ID9IptrkTlOvis0bCOcUs/kDnKPvqDnqyD8tveWc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544291; c=relaxed/simple; bh=WiqpJDuzZ0MkcljcN52DPJR59sV0PTedJ6H1tMhOPz8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=adN9gnEBz9meZbKcEG73JtD4OBKJN8Ar7uvvFbRL4fZgwYyM9CTX4pAWPteYO/fRNN9xRe1puCGkbJ3apu9Ko/UU1GMbMY8MqS9klyLjcanZSAG/VB10m3Tk7sWeE3lgeOMAcZv46huDqZrHXZVcfJSj1M50z4buS+I7NSOzh98= 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=b1cUz8hH; arc=none smtp.client-ip=198.175.65.18 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="b1cUz8hH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771544290; x=1803080290; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=WiqpJDuzZ0MkcljcN52DPJR59sV0PTedJ6H1tMhOPz8=; b=b1cUz8hHPN2ww70FHSaNAP3XVG8sDfI+XWwPcbo2GSFhsseMrtsvQ5yb R4DFEtamPl3rkwSNS/6y4iaeoRN0okKXGC78+wCDZhGl7pkjj7/KjRacW qiAQ65E1WVottjic2UdiJvcU/rlaC+CQgYquiBYxMHMACaW31EI4qF2uM oBRMXjd64ks4WIxGGuvos1xFdEUnzrA4xj2wbkhbaSlCTNKK5CY5I78fJ crAWXYOMdZuOodR8eVMQC8ybhenXw+tzba7rqk+DZFEYHU7j+3HHcstMi b5J7K6h21HsmLh1wzKorWN9ZclOoF0RX79GGbJDM8ilndWl0ft9+IWyop w==; X-CSE-ConnectionGUID: yB2CiRyoQuGbqXnuAJ4OeA== X-CSE-MsgGUID: fl14sga3TXC6sFS2xU7FTA== X-IronPort-AV: E=McAfee;i="6800,10657,11706"; a="72685715" X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="72685715" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2026 15:38:09 -0800 X-CSE-ConnectionGUID: BH2OffyoR9uHvHOXUQUTpg== X-CSE-MsgGUID: /TJQ9ldQQQSkm0aompqjwA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="214805188" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa007.jf.intel.com with ESMTP; 19 Feb 2026 15:38:09 -0800 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 2/5] x86/traps: Consolidate user fixups in the #GP handler Date: Thu, 19 Feb 2026 15:35:57 -0800 Message-ID: <20260219233600.154313-3-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260219233600.154313-1-sohil.mehta@intel.com> References: <20260219233600.154313-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 --- 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 5a6a772e0a6c..e21f8ad2f9d7 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 Sun Apr 5 13:04:57 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 E13B630BBB7; Thu, 19 Feb 2026 23:38:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544292; cv=none; b=P0x1Q5yUtunzwm+7vy9I2yMcomof3EMEvxbXB1ulhYuDJDDCyErFNFJBmVZPHtur2EQVbC6/7zxP6wpalm/L93e/z+C6W8zf2F5zLtYu4MeNJ8cy9VbMW8XVtQuQJrjC/t9RJ5EzOQdSnWVvaVfcR4BX859tCDWCuSKAQxUO5/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544292; c=relaxed/simple; bh=MhOZJua0PouCiI8MZEs15/KCfXiv1uJqvK9DjTy5C1s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K0oWH6XDxAUgWHrrq7CWeuL4fH0Z+sL4ehGBZk3muoQvETNaFuQEQiS64y7XpZIsaqHI+6e3p7DDgtzeYbGJx2VfnJHMkoUWIOvkU/FhY110rixtWFihFduDk+XfmMgPytJb6GN3T9bT5lkb4PzITJS8NLwLDxZm6jrJ/tdXwSo= 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=PA2vo5mG; arc=none smtp.client-ip=198.175.65.18 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="PA2vo5mG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771544291; x=1803080291; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=MhOZJua0PouCiI8MZEs15/KCfXiv1uJqvK9DjTy5C1s=; b=PA2vo5mGbrG9ZFbt9xNdfMO3gQqeOJiLoT1nDgx4JhhJSPnSVuSh7++J 06oj417i1FJMSpH8kUYYeIh+zx03HvBmG+cY2Bo15eQYJZvNTF9/MSYFz FS420Dz/FqmkYWllGxb9EwueWYiyk2TarGIe+yWv6cFVhqQcXd0CkkCSE h5LcQu9aBHdSw9YvwSJ46B6SY8k9NqJRWLL3DrkWJBCLLKcyx8Zb6EZ3W ZTshXeQEWZa2ko7rP7wJk34H+H8nB/XmttxfCJVMOyVlpWZcwoNyB+gtw X7Bg2QSr0h4ru4sfbkK+lCP4AcpyZvrP6DnH2YAnAGGm8SsZYhq6jynji g==; X-CSE-ConnectionGUID: QVNKATXCQMOVGRdEeMPeCg== X-CSE-MsgGUID: Kg7kKFFiRDaXO1s4KMEarg== X-IronPort-AV: E=McAfee;i="6800,10657,11706"; a="72685727" X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="72685727" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2026 15:38:10 -0800 X-CSE-ConnectionGUID: qUb7aequRw6F2kKnKn7Z1Q== X-CSE-MsgGUID: 1Kdc/I9iTtyjtbIpjsIa3g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="214805196" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa007.jf.intel.com with ESMTP; 19 Feb 2026 15:38:10 -0800 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 3/5] x86/vsyscall: Add vsyscall emulation for #GP Date: Thu, 19 Feb 2026 15:35:58 -0800 Message-ID: <20260219233600.154313-4-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260219233600.154313-1-sohil.mehta@intel.com> References: <20260219233600.154313-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The legacy vsyscall page is mapped at a fixed address in the kernel address range 0xffffffffff600000-0xffffffffff601000. Prior to LASS, a vsyscall page access from userspace would always generate a #PF. The kernel emulates the execute (XONLY) accesses in the #PF handler and returns the appropriate values to userspace. With LASS, these accesses are intercepted before the paging structures are traversed triggering a #GP instead of a #PF. The #GP doesn't provide much information in terms of the error code. However, as clarified in the SDM, the LASS violation only triggers after an instruction fetch happens from the vsyscall address. So, the faulting RIP, which is preserved in the user registers, can be used to determine if the #GP was triggered due to a vsyscall access in XONLY mode. Reuse the common emulation code during a #GP and emulate the vsyscall access in XONLY mode without going through complex instruction decoding. Note, this doesn't work for EMULATE mode which maps the vsyscall page as readable. Add an extra check in the common emulation code to ensure that the fault really happened in 64-bit user mode. This is primarily a sanity check with the #GP handler reusing the emulation code. Signed-off-by: Sohil Mehta --- 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 5c6559c37c5b..b34c8763d5e9 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, @@ -282,6 +281,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 e21f8ad2f9d7..a896f9225434 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 Sun Apr 5 13:04:57 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 73B3B318BAC; Thu, 19 Feb 2026 23:38:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544292; cv=none; b=YQNhmBZcJqe3y5N3UA1NJv0M2LMP9G9/P0teFnRI2rnzJmqqSwhDKsqTlYxIsB0n+XRTTbInwRh3/Xhtwk6yaituwOeLyFknRlGlDMNuvm6T+rQjGIoBs4cUxvz7M3pL4M2CneIa3rEIc+j1B/qoY/YgqjgGvf9twgbPEeA1bqs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544292; c=relaxed/simple; bh=sSsR4pwoJ92DEAcXzaojB/1nkH/EgjXqXgmy2XE2Q38=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ikNBdSfvKV0YYifgufmrxl8gkZDzn1ZSshIGcfV1jdcYGAVLJjzApOegMGsz/vc3khBty3EPJtCYzU5kjyYN+U8Ym6UagqxKrG9gFs3ZLPSffa1O++3B7q5gUHyY3dHQRYfdXH3xzRpOQtMTmtCDozb9UsvOjgKQLRjkwxld8F0= 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=S/Y1bhLD; arc=none smtp.client-ip=198.175.65.18 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="S/Y1bhLD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771544291; x=1803080291; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=sSsR4pwoJ92DEAcXzaojB/1nkH/EgjXqXgmy2XE2Q38=; b=S/Y1bhLDxiBTfeTcBQ2sp2AGuM14S918jNLfjXQWM2F+la85XZ1J2Usx w7LFM4eMpa6yJhVh8F8Bv1ai7jX6UUZv0oufA/qrXi/KuzW8iPltIqe6E fjzrKHuovPuar1mqgOZv/0/pDMZJHAPQ+Gv2OZfNo7diAR0EzXvp5oFNV 88V4BtR+zl8WS1AsPDqpcjebVurOVyGTRy2XA4Ln6o/RufCUAL5+WkqSf EQ799s/oqJCVzsHIW3ARHmtfP6NHXOGapXcT98X2DD90l/ANVqgRZxesA 192UHqQM3lfhuNDXbUOeHDm5Uudjx0qK8Farrf99XbdWaolIJGTx1kWTO w==; X-CSE-ConnectionGUID: Gcm71SV9Skq9hdNohEcpcQ== X-CSE-MsgGUID: ZZ3MAlX8TvSLaiRwblUQiA== X-IronPort-AV: E=McAfee;i="6800,10657,11706"; a="72685740" X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="72685740" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2026 15:38:10 -0800 X-CSE-ConnectionGUID: QtTT3sP2Rhe5K9vTdkp6+g== X-CSE-MsgGUID: 72PuIhxnQIWYFHmmgoLlhw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="214805201" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa007.jf.intel.com with ESMTP; 19 Feb 2026 15:38:10 -0800 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 4/5] x86/vsyscall: Disable LASS if vsyscall mode is set to EMULATE Date: Thu, 19 Feb 2026 15:35:59 -0800 Message-ID: <20260219233600.154313-5-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260219233600.154313-1-sohil.mehta@intel.com> References: <20260219233600.154313-1-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The EMULATE mode of vsyscall maps the vsyscall page with a high kernel address directly into user address space. Reading the vsyscall page in EMULATE mode would cause LASS to trigger a #GP. Fixing the LASS violation in EMULATE mode would require complex instruction decoding because the resulting #GP does not include any useful error information, and the vsyscall address is not readily available in the RIP. The EMULATE mode has been deprecated since 2022 and can only be enabled using the command line parameter vsyscall=3Demulate. See commit bf00745e7791 ("x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE") for details. At this point, no one is expected to be using this insecure mode. The rare usages that need it obviously do not care about security. Disable LASS when EMULATE mode is requested to avoid breaking legacy user software. Also, update the vsyscall documentation to reflect this. LASS will only be supported if vsyscall mode is set to XONLY (default) or NONE. Signed-off-by: Sohil Mehta Reviewed-by: Rick Edgecombe Reviewed-by: Dave Hansen --- 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. --- Documentation/admin-guide/kernel-parameters.txt | 4 +++- arch/x86/entry/vsyscall/vsyscall_64.c | 6 ++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio= n/admin-guide/kernel-parameters.txt index 9e3ae4071c4b..28aaebd9ca49 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -8283,7 +8283,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 b34c8763d5e9..e0faa4ca0382 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -62,6 +62,12 @@ static int __init vsyscall_setup(char *str) else return -EINVAL; =20 + if (cpu_feature_enabled(X86_FEATURE_LASS) && vsyscall_mode =3D=3D EMULAT= E) { + cr4_clear_bits(X86_CR4_LASS); + setup_clear_cpu_cap(X86_FEATURE_LASS); + pr_warn_once("x86/cpu: Disabling LASS due to vsyscall=3Demulate\n"); + } + return 0; } =20 --=20 2.43.0 From nobody Sun Apr 5 13:04:57 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 EED4631B108; Thu, 19 Feb 2026 23:38:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544293; cv=none; b=lPdG8OQb559q2pArhq8O/wTnoKXhresG8CjnhcnyOHWafvDr/RrpnRgYLUPXwjDXKgD3aPq6KvPki891HYxz848hNUa3JfzYpeNw8qV127LieIe7obgeYrLKRHzO0ssd9gzLiMdPKs9E65rPoq77wU3KMvjWfcvAPXEUTvRMtPM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771544293; c=relaxed/simple; bh=vH54bd3bnODuU9YcmKZXZsBBTrynsYxwRm8fyHLVIK0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uRk5macQVESuR/b/pWJdu02Y9sYX5xTMj5FF9VEtFvo/Z5XRDQ9XqYIGszrLImOkGYJVfuaoOtDKTU+mQAsYbWv6bgMK9P+JbMLxWgqwzmJ87b8X6NdAiX+sg9koJDB2koeVOY7YxJS18KpHKuzjuP6furQSf0xmWFCHTjkCjGo= 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=hFxc3XSZ; arc=none smtp.client-ip=198.175.65.18 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="hFxc3XSZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771544292; x=1803080292; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vH54bd3bnODuU9YcmKZXZsBBTrynsYxwRm8fyHLVIK0=; b=hFxc3XSZp31wvszXvVV+20YsAxk9LP6Q5RTICUIv45omOSdjkazVLiQS QGh009UrMg4oKYyCwYcEfmJUViGTnkZ4qQqKRkRhco5JR6cJq4Xk+SEJ7 S6YfcjZaNkHjzZztwxT3EMH1rp+ceok+yIXWYwZ3XiSdDpp29dZjCdhTW 9M72TVnReMiBiuuZsNjE5UuQG1gqITWF7+Iqtl/2ftwhPtdqY3O8djOH2 H1MzQjBkrjVN5gE94Ge+246OS1YCVsIMylJtGcfv6N897gN7ZCDR5yMgO agf7AezKlYRcoUzgyjNPicvE9d+265CZDx1/xXU7+TFqg6Xaumogj8J3O A==; X-CSE-ConnectionGUID: owWDhfvERb6KpqT8MIvfNg== X-CSE-MsgGUID: zcqspG0sRUGgW3fcNrvbzg== X-IronPort-AV: E=McAfee;i="6800,10657,11706"; a="72685755" X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="72685755" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2026 15:38:11 -0800 X-CSE-ConnectionGUID: bdB+jvocRIesOgkrLgHFOw== X-CSE-MsgGUID: p3tWiBwnRX+mvdC6QEpnuQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,300,1763452800"; d="scan'208";a="214805207" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa007.jf.intel.com with ESMTP; 19 Feb 2026 15:38:11 -0800 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 5/5] x86/cpu: Remove LASS restriction on vsyscall emulation Date: Thu, 19 Feb 2026 15:36:00 -0800 Message-ID: <20260219233600.154313-6-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260219233600.154313-1-sohil.mehta@intel.com> References: <20260219233600.154313-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" As vsyscall emulation is now supported during #GP, remove the restriction on LASS when vsyscall emulation 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 --- 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