From nobody Mon Apr 6 09:15:06 2026 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 E859E3A6404; Thu, 19 Mar 2026 22:59:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773961170; cv=none; b=TE7zM+lQjj2bYZn56TNJj/hUvBF5gQZgt8qsyALj4k9NwjlK7G0ThnO5shv7+VjgVhV5q7pFdErQMWNG7n3hbopFzVuR2GUpds9IQHka/IHKpk8YuDbVO73iD4Dg42sf2cZVHfcybfxMu2gFbJBsoniUCTOSBGrH+HLQ7CV9cKQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773961170; c=relaxed/simple; bh=vISI9hQNtYwmcBp5EhcMzPIQOv9jNgQeUWs4OX/4uhA=; h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version: Message-ID:Content-Type; b=Wci7zHBHGI0Gjm7bLNWVRWmEPHBVJBKp3fZBlFs0vnVpDu2XwwxJDUxN7CxQ7zIRIzPkJA1ZRBeWrFYu3P/dNqLe8FMqJnEaEyn8N2z0amoS/I043ywzeytpIjQ5jtFpKwR+ZxYdbW0rY0Az+Dwx7My2SO+6CdlECGHl7XzxeYo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=409VR9lB; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=m0I/18al; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="409VR9lB"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="m0I/18al" Date: Thu, 19 Mar 2026 22:59:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1773961167; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sM5z5hCWSd1xk8jiP7N0Mg7Q9JKI+PuzS25PMSpBx9g=; b=409VR9lBj5+3h1Kf0s9LraOrAI2KohSPvEwro7DEp5W4475++YiWdXvRDzrDvKVCqrmeyF +PIwsqemrdExTE4ESFBBvf+5CNPUAPP7GWxpqEl60n8QOI+f7AFdkat3fRmiom0O2hDRf+ ue6wiMXE96nl0JZungfcjt3w5LevgFcmYUkk8CREhKn4raVuvx4Qi55R5+jcPif5cG7paU M0SUilq5nzL4r+sj6azr719gjgokkGplKU0KKOpCk3dX5j5IftGwS5YVouIaP/cBY1+6aq 7Nm72vwVvsBuWaoL+OsaDLr+mU2pYDvizCtz0EyHQlDvCg08bgzr0dC3Lkl1TA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1773961167; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sM5z5hCWSd1xk8jiP7N0Mg7Q9JKI+PuzS25PMSpBx9g=; b=m0I/18alqqVREVJUZqh4giqkDWlseliBfy/E+xHjzSO1tvv+AlTe6m8Uq17XtfO7PG270S aKStHkCQSHKcJkAA== From: "tip-bot2 for Sohil Mehta" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/cpu] x86/vsyscall: Restore vsyscall=xonly mode under LASS Cc: Sohil Mehta , Dave Hansen , "H. Peter Anvin (Intel)" , "Maciej Wieczor-Retman" , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20260309181029.398498-4-sohil.mehta@intel.com> References: <20260309181029.398498-4-sohil.mehta@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <177396116611.1647592.13090227647714431050.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The following commit has been merged into the x86/cpu branch of tip: Commit-ID: 8376b503b0f18d7425b42621798518e61e2ea601 Gitweb: https://git.kernel.org/tip/8376b503b0f18d7425b42621798518e61= e2ea601 Author: Sohil Mehta AuthorDate: Mon, 09 Mar 2026 11:10:27 -07:00 Committer: Dave Hansen CommitterDate: Thu, 19 Mar 2026 15:11:13 -07:00 x86/vsyscall: Restore vsyscall=3Dxonly mode under LASS 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 Signed-off-by: Dave Hansen Reviewed-by: H. Peter Anvin (Intel) Tested-by: Maciej Wieczor-Retman Link: https://patch.msgid.link/20260309181029.398498-4-sohil.mehta@intel.com --- 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 398b1ed..e740f3b 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 f349023..538053b 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 614a281..0ca3912 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; }