From nobody Thu Apr 9 20:25:37 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 89A3335F165; Thu, 5 Mar 2026 21:42:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746981; cv=none; b=eXcM67+OVYp2lppLnMyu2A2ve0iEYQlnlDNFYwnJp3TfOckf4zVNjUCFrUfSrWsxLmfz/i1gXxB6/wnba97rV68LVbh6SqovD6J6D6kyYlbnWDa1wSdWkFMVvxmLzhtbXagnJJVT098fpz18dTCjlkJrtfpLdf0khTCOfGoEeME= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746981; c=relaxed/simple; bh=Ssb2T99f3J7xRfe8UCKuix8yfeF9Ye6YsvU51ZnSua0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=h5HxAHXj6IO6FNv15RmSlWSLXrA/rOHH1YL+1owuqTRhiKfp43+H7wtAaIaPhAeTNwxkrRufDOPbZqyXnrNXdJh73RPhfhabgGx4CRtVFsTFR6g9QeApUhAt4WIz9pL1eAedXdwmm6NlJXCKeamfLcIM4DsVZxHFNkHlG4CX+3w= 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=I0vWRyOv; arc=none smtp.client-ip=192.198.163.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="I0vWRyOv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772746979; x=1804282979; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Ssb2T99f3J7xRfe8UCKuix8yfeF9Ye6YsvU51ZnSua0=; b=I0vWRyOv4esxyw3H5+gvkQXQUOatq0IufAftOMqy909LiuZjI22KvDc2 DjtCn44TmqJJN3W4y35L01waOzNEp5LiZe+Mgh1Qzmq1g9rTwcL54FTzR +VwqNesTCAktdC9Dh5Lt3qnBQAZ+9Ge16YUbf2JZ3KUIhOp8CVgIfDpjq pylly+dYbWLtqnI2E2Xzk5yPAOC27neaD0WyJJc8LHGnLMJEj+tlRQNkL O8BkNzTpaKALW0GExKMDcq5CkXfKXVtXhYx04CpbNJ505w2xUhvWjD3mZ 0PXZGq/8pdyfww+5TlWcX/qJlFqBNiJSfezrPZ6hcJiAHFYEAT3GH3Igv A==; X-CSE-ConnectionGUID: /SKs01jLQj2y/SiMvdgWug== X-CSE-MsgGUID: VCP6R7gbTMWvxqKUnX1BnA== X-IronPort-AV: E=McAfee;i="6800,10657,11720"; a="73043865" X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="73043865" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 13:42:58 -0800 X-CSE-ConnectionGUID: C4E4I0u7S4mbCVnJl8PfPw== X-CSE-MsgGUID: rL51ta6qRO2baTRgxxXOKg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="215562933" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by fmviesa006.fm.intel.com with ESMTP; 05 Mar 2026 13:42:57 -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 v2 1/5] x86/vsyscall: Reorganize the page fault emulation code Date: Thu, 5 Mar 2026 13:40:22 -0800 Message-ID: <20260305214026.3887452-2-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260305214026.3887452-1-sohil.mehta@intel.com> References: <20260305214026.3887452-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 --- v2: - No change --- 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 Thu Apr 9 20:25:37 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 250C135F170; Thu, 5 Mar 2026 21:43:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746981; cv=none; b=Ez2KKVUVd1kq2IxLJqKJWzWv19Q4jU+21mo4DR/ThnSCDQBohv1r0IDbDddbexD7PriV1a0113jjUWc7lyE15IbcDZxUDqBQwn5xlkT9tpoG83eDynT5CGlTmEy/FkJBEZOfDjZ3rtp/LuCRIhCe9f+AxoXdFYIA0+fUq7BgJXE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746981; c=relaxed/simple; bh=jm5pN4JlqYTYJWQIqJwy8y3zCh99ZeZ0PpUwm5waDa0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KYt+Vwhpv3GC9wT4DVP8KI32CeE6x1S+8kgDwzCRaBqGyJ9jXVUvDM2gGG9NlV4qbt1mb/VBVOOUvrZcYHIRfqt+E/pf/Y4x+zn+mtDv8QPATL/jcTPlVpvgfLVFFovESaTqkCtPjklQkV96PwmunN8Fy/f6rQWKRi9IbQ4BPks= 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=E5O5imiO; arc=none smtp.client-ip=192.198.163.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="E5O5imiO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772746980; x=1804282980; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jm5pN4JlqYTYJWQIqJwy8y3zCh99ZeZ0PpUwm5waDa0=; b=E5O5imiOCjsUYuMa+r4Rz/ETHG5FyKO9OHjyXPxeFR1H6ckaDASmaxVm u+S5lW5yWZ3F66TGvElKCYSWBC4gT4Y75pa7VriYjLCVoGejZkKJQ6clu 5k0WaizL0vsk64NJpd12gBcxW5p5c1sv2LAOmZxtdcsb+wg9GS/A0/aaO 5cL+/lDBWyo0Aw0YAtvgAH2diS/NQ/dEJ6ljyQFzMkQdeCVbiTthyxQyp 95PsAvT+Y/Ypw4JtnB0cDiTpbnjSzn+DS2b1kIwXMhDJbKJMi9pxp7a4q TTnH8KKbyDrG5LYDqRtLYM6ZvBCO4JZmQvjNsFlR237qZK0wJWxwMA5eK g==; X-CSE-ConnectionGUID: UxqL1VugRoWJ4q1Uw40QLg== X-CSE-MsgGUID: rIaj7nIPTYipZ8DYa2iSaw== X-IronPort-AV: E=McAfee;i="6800,10657,11720"; a="73043877" X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="73043877" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 13:42:58 -0800 X-CSE-ConnectionGUID: BO+zPG9BQ8+a9Fk2YA4S+w== X-CSE-MsgGUID: nJ+hEHS+S/iXez/VT3JUBg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="215562936" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by fmviesa006.fm.intel.com with ESMTP; 05 Mar 2026 13:42:58 -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 v2 2/5] x86/traps: Consolidate user fixups in the #GP handler Date: Thu, 5 Mar 2026 13:40:23 -0800 Message-ID: <20260305214026.3887452-3-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260305214026.3887452-1-sohil.mehta@intel.com> References: <20260305214026.3887452-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 --- 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 20:25:37 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 C78B735F180; Thu, 5 Mar 2026 21:43:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746982; cv=none; b=BddsQOgDhKQJ266mfmIO2Kdf35aeR5wFnBihXXylitU0u/uuPjDy1jYjhnTUpGlFQ6v0ZVih5nyr/8e0VLcl6Rc3Ayto6EE8EF7Kpsjxs4xtVnHelgNipJgi1UlCMP027cIXgUajiWKzPOIX78XU0pzbJQK1vlP5mtfKO3XgLss= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746982; c=relaxed/simple; bh=z2r3KorHteDgQLOuiYVS8zVcbfrFsAeLqgofdqmOQ8o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kOvvqJfu92Ubf0FjmzcsX5hkC8XEFQWn9XxX6VsHNdjoM2IipILplZaHUShpHWbvAtgmMZTcUNamwtoii8l0KL6p+5UYCrDFqp7hWi73nHb8IuwYF5WrBZds6BX8ou/NFbAKDCJs7pd6PFbWklTu72/3/FkVnTHBsXmWYKWKwYw= 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=UDj/j6PP; arc=none smtp.client-ip=192.198.163.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="UDj/j6PP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772746981; x=1804282981; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=z2r3KorHteDgQLOuiYVS8zVcbfrFsAeLqgofdqmOQ8o=; b=UDj/j6PPyAUwIldx5pG7gsUutvQzgkBxJ8fomkGb9qWiTOpEkQoupTP9 07oRoo7TDSxYE3mVceChrwY1UIbDfaBAyVU2g2fbH4okhP45w50cAo0I3 ejnvjntcG2Jc8ag2CuMdCVJbqsvcvpShI8NYHE+DUZneIHRDJ7123wYhJ goaZT+NLsv/lvNReelPe+0H2gvKwfhZws6BDYIWQG1Iggz7UjR0K0U1hP Cz0Zvt45j+uJH8QLkuD+GFKw4BTL2vsL/i6umpjHZ32nkPYLBeZ+l+Ja/ Ew91rBfrRFAeJmnf8qBtYpaX3+mHFj0ZqELfDsq4vto2XTqQ46GkWTr3V Q==; X-CSE-ConnectionGUID: +G/2GHtNRkSCBf0yze5gkA== X-CSE-MsgGUID: eUbiIp2xQiGjzn0gEzstlw== X-IronPort-AV: E=McAfee;i="6800,10657,11720"; a="73043889" X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="73043889" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 13:42:58 -0800 X-CSE-ConnectionGUID: heZ3F5HrSmi0ewMtaxduXA== X-CSE-MsgGUID: 2QAQxoOOSLeUpvJs0b0Jbw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="215562941" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by fmviesa006.fm.intel.com with ESMTP; 05 Mar 2026 13:42:58 -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 v2 3/5] x86/vsyscall: Restore vsyscall=xonly mode under LASS Date: Thu, 5 Mar 2026 13:40:24 -0800 Message-ID: <20260305214026.3887452-4-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260305214026.3887452-1-sohil.mehta@intel.com> References: <20260305214026.3887452-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 --- 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 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 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 20:25:37 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 4BDCD35F18D; Thu, 5 Mar 2026 21:43:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746983; cv=none; b=eQKP1rYVCrxMaBBAehJ8+U7hB11PoDJoyOP2gHYcHOm0HCmuV9HULmueHxBUqCSk7JI6wNdNY1ADlQnKhz6VZDHPISUXc9e+AWvEYnMhKJxwilSKRaiBpyY+0n4vCGT0E9tM6bG6puDLBEDNo/pE/gyOJVwJp7RPSfWQB/odaOo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746983; c=relaxed/simple; bh=QjkJwUpOlN6aV8Di5dQX1//cFiVDEulafb3/sxMP7hs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MjHN77tFTH1VKb6iZEbkLvmo/aIBtR+JLEA9GGitp0phIwnYHzqPg//322hfeX0gp7+gmtG6bAc1DxjQdeDgrZTE59Jo/eTosLKG7AV43mie69GJursvXC4UH5TsFURqXpBY0Y62/A7Q5syQzOXbqbZrM4GKQdjWNJIVSCoNhcg= 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=IfR71Yrg; arc=none smtp.client-ip=192.198.163.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="IfR71Yrg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772746981; x=1804282981; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=QjkJwUpOlN6aV8Di5dQX1//cFiVDEulafb3/sxMP7hs=; b=IfR71Yrg1maIyCorATNIH3lrjB3KD0IMXti2XdfQK4soM/0eHir/pFAb Kr3vmTVXHDWTiG63PGbu+J78Aj2WnRIUQ9Gp3UzJ4xBnkVoEDwMZUyJv9 YMJMgsf3OzYmsV1+5W3nYl7yk3/miDULw8XzrElnz5a7iJbohnLSOGZ0h pZzS9IpRpsAjK4SO+my4pqbokWXms6lX2BOEcMeDAbZYSdAJWwqA32sju nhw/OGMWun6E3USuQBTJiSnRuYDBjfbZ4+BS65o/EBPGEE6gpVjXeN1+7 NE17iYV9Exbl9cFKd7Se2fOGlY1J/1nl8RSzyeX5DchcMzr94DBPycRoQ g==; X-CSE-ConnectionGUID: McNPOVgCT8KReNz/CNCqSw== X-CSE-MsgGUID: UmqfwP9EQxKvwcWlHMuzCQ== X-IronPort-AV: E=McAfee;i="6800,10657,11720"; a="73043901" X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="73043901" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 13:42:59 -0800 X-CSE-ConnectionGUID: Sd0YGaHkSseS3EIDFAD50Q== X-CSE-MsgGUID: T668Ch1UQymkNIiWGIV5hg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="215562949" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by fmviesa006.fm.intel.com with ESMTP; 05 Mar 2026 13:42:58 -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 v2 4/5] x86/vsyscall: Disable LASS if vsyscall mode is set to EMULATE Date: Thu, 5 Mar 2026 13:40:25 -0800 Message-ID: <20260305214026.3887452-5-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260305214026.3887452-1-sohil.mehta@intel.com> References: <20260305214026.3887452-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. 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 b34c8763d5e9..215ae07dd3c7 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 20:25:37 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 6F05D35F19A; Thu, 5 Mar 2026 21:43:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746983; cv=none; b=WfqIlo3Cehx+jiybdT/VW0w58c16nr1cy0ccuDhGMSTQK+0lFKMgTkkW3961G+g2DhrMclTr4FcU+jU21wJKUwiUR/19VhPwlQhkAS2OnL8dvcYc5j/wEn2Dh0x9xSAWEtXyfa6dXj8XLiweHJ6EZUIrleZDKb1YqaK2BoV55SA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772746983; c=relaxed/simple; bh=TkRy/P4zS6HL/scOhBZsKuA26qdvarrGBX3iVkXHy4w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ab2DxWy7Zp55WUvDfgiJQxQ9c+YsbGShLMxTS7h/AQlVst1NWyLyQ27OL0hIR4BrINzt/8zLg+wvlFFN8yWWlc2V3DWxxPM6URhqnCxgjac0W+gzqPvT+cs4v2AfVNheu3MoEPgItSkrodB0wST/wo8moQpk+ictpZH76Pr3U30= 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=P1KUwKOw; arc=none smtp.client-ip=192.198.163.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="P1KUwKOw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772746981; x=1804282981; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TkRy/P4zS6HL/scOhBZsKuA26qdvarrGBX3iVkXHy4w=; b=P1KUwKOwP75Y+S67kxui00CuiMWt2V4iWp3SnFS0Vb1Od7/LInEw1QKO qHH4luH6BwcwMfhyGSRqv9RgLhKHG1lPOPZ+DITrwb823yUmn6EyhCQj5 kLwdHQY0MK2MA9cqE3tOX+MFVrZ8GgVs/8AtQxRB8mysjEUeRuwfVOdZJ qic71bCBKl3L7ZeJus8v27C0C75hOrmq3QZ0ER+UMl6Wca+tQfhjU2ZYe nOcxDMbH4yaG2xQ2nvvJCvKiLDhURkdNiZtVt45VSoxV+oQHUqYBlXik1 Fo50g6E68jLiCHfudpG14ExGOB/OxE88jimoa9O2yGSRlyKQmg3MbmxRO A==; X-CSE-ConnectionGUID: m4pFDetmS4uubZ4ab/BNOw== X-CSE-MsgGUID: EqCrCGRQSZqqEffXfJ+/Xw== X-IronPort-AV: E=McAfee;i="6800,10657,11720"; a="73043914" X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="73043914" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 13:42:59 -0800 X-CSE-ConnectionGUID: 3VWFPrsIRcewzED7cN5dsw== X-CSE-MsgGUID: yXrLcB7KRMScgclHrkN0MQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="215562954" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by fmviesa006.fm.intel.com with ESMTP; 05 Mar 2026 13:42:58 -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 v2 5/5] x86/cpu: Remove LASS restriction on vsyscall emulation Date: Thu, 5 Mar 2026 13:40:26 -0800 Message-ID: <20260305214026.3887452-6-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260305214026.3887452-1-sohil.mehta@intel.com> References: <20260305214026.3887452-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 --- 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