From nobody Tue Apr 7 09:05:36 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 E4EA734E774 for ; Fri, 13 Mar 2026 19:25:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773429941; cv=none; b=ts5CvAn/39jURWfD4OPYmy3GoOciRkyV1uaT5OmLsfaQCqCxqGIN8H6ywgpzu9tmohiakc5CWWv7eiN0Ro0Hhl681mIaiLZTfGqjHFIziGNFfPvtKdUzX8IzPh4ZfJD7hn1TBmBsIPMnc7tOgdcaNIrQR44pbPWc97YFHzzBSlg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773429941; c=relaxed/simple; bh=8ld+z2MCEpb+OtQ2R5x1Hhin/6MRMBPQ0LiVTTKP4fY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HZNvOAHN6LAhs3LauGnLHn7wzyzOYcXwvHcxyy2UvKrt+lt+AQOJHk/9JRhPzmbcgt/4QQpQf2hX38ExGeX+QgpnF59z9yE6SwQg0yatXDQyV/YZRAya+5iAb6YsjNE95UM9riDwGBpI9NH38kMhiqqjk0fJhdA30DwgiSQ3TWw= 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=lOC9AB12; arc=none smtp.client-ip=192.198.163.9 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="lOC9AB12" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773429940; x=1804965940; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=8ld+z2MCEpb+OtQ2R5x1Hhin/6MRMBPQ0LiVTTKP4fY=; b=lOC9AB12eXAakr4IHS72kkp4cAsjOC87YLcSBnK+Lf6ETkdFy5nm9oW1 /YAJRlGUvK+sGSfEeUv8eoyYf6usqmP1bFxepeRx0IMXN+mpJzVESV7QZ t7VC20XsJnzvQFQJ6YGxJJCL2nJi4G4kAeT2JRlFCDVw4Rf9/GoFIbr9d zYvzNqIc7mRafeZByiOBaNdGfVzYHLPWU+fss2iGrWiCAjtFgeUMhw0D3 Vdo2vY+j/wRvfYDr83nPuEnZ8DXNQ99bDrDjmRjR9aRfMPS8Xs/zcEAFa /INA5g76O+0TkTVbBDZUrxgjqe523Fga0wv6cy5EFr7hRDCehLFYcZAHq g==; X-CSE-ConnectionGUID: oV7FFn37QHiRXyHOeKIgjQ== X-CSE-MsgGUID: vJ9EX2hsS2CKKX1Ef6c7hQ== X-IronPort-AV: E=McAfee;i="6800,10657,11728"; a="85246622" X-IronPort-AV: E=Sophos;i="6.23,118,1770624000"; d="scan'208";a="85246622" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2026 12:25:39 -0700 X-CSE-ConnectionGUID: aHbtPCbWQVepydJxNcbT4g== X-CSE-MsgGUID: W/U0sZfFTseT0aRdPThjug== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,118,1770624000"; d="scan'208";a="259152574" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa001.jf.intel.com with ESMTP; 13 Mar 2026 12:25:38 -0700 From: Sohil Mehta To: Dave Hansen , x86@kernel.org, Andy Lutomirski , Borislav Petkov , "H . Peter Anvin" Cc: Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Sohil Mehta , Nam Cao , Cedric Xing , Rick Edgecombe , Andrew Cooper , Michael Roth , Brijesh Singh , Jarkko Sakkinen , Tony Luck , linux-kernel@vger.kernel.org Subject: [RFC PATCH 1/2] x86/vsyscall: Avoid vsyscall emulation when X86_PF_INSTR is not set Date: Fri, 13 Mar 2026 12:23:26 -0700 Message-ID: <20260313192327.2089471-2-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260313192327.2089471-1-sohil.mehta@intel.com> References: <20260313192327.2089471-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" On systems that support X86_FEATURE_NX, X86_PF_INSTR is expected to be set in the PFEC when a #PF is triggered due to an instruction fetch on a vsyscall page. Commit 8ba38a7a9a69 ("x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall") changed the requirement for X86_PF_INSTR to be set because X86_FEATURE_NX may not be available on some platforms. Vsyscall emulation now relies on the fact that, in the case of a #PF due to an instruction fetch, the RIP will always match the vsyscall fault address reported via CR2. The kernel still issues a warning if X86_PF_INSTR is not set when X86_FEATURE_NX is enabled. However, this warning is almost impossible to trigger unless something is very wrong. Instead of continuing, avoid vsyscall emulation in this extremely unlikely situation. Suggested-by: H. Peter Anvin (Intel) Signed-off-by: Sohil Mehta --- arch/x86/entry/vsyscall/vsyscall_64.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index ea36de9fa864..b1f8f8a57b02 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -282,8 +282,9 @@ bool emulate_vsyscall_pf(unsigned long error_code, stru= ct pt_regs *regs, * 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)); + if (cpu_feature_enabled(X86_FEATURE_NX) && + WARN_ON_ONCE(!(error_code & X86_PF_INSTR))) + return false; =20 return __emulate_vsyscall(regs, address); } --=20 2.43.0 From nobody Tue Apr 7 09:05:36 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 070133DFC77 for ; Fri, 13 Mar 2026 19:25:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773429944; cv=none; b=nZDXfpzCluhwEGnhCRqdUxwEWHHoO8HzvQsVrtNBDu9x3Fg5Ob9IcOEFfe7RPVwCZpl0+wC7nK8xMZmHETsZmoy+bRTHLzUidG4hhq/AqOCBNOhzjlPsqLyic0u/XawuVX9Tyry0Iav0j88Lm7e1Ekye2s6NMdVHcv9W3NLd76w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773429944; c=relaxed/simple; bh=gRJ0rd00fZ+7G/48F2b/Y11jG/iZgT6hw9BaRynTrw0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QdZbDiL4mIO23uPaasgXmrV13zmzQHSt+argR4BdPwL9Hla1U06fsEqI9MHSnARg6J13vTAa68Kv9rOAy8U31NTWGyXAzFctrLGgqUtAwB9XdR+iorknbBz+FYM2K+7RB1tzLdIJVNDkDX08sWnkQbgowJMOZALn9wEA0kAwCxY= 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=EktkaVs8; arc=none smtp.client-ip=192.198.163.9 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="EktkaVs8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773429943; x=1804965943; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=gRJ0rd00fZ+7G/48F2b/Y11jG/iZgT6hw9BaRynTrw0=; b=EktkaVs8Bkgds7PCUsx0pAYqtrbC2/fEdwNdy7oHFARx1VpFOOwvv5xY 5DqpUj675HLZYqBUcq4UazZkaNnLilgYkbAFTaFw0Rg/HpVjQ6SJZMFZK Nmwwl1nnZGgOSQb4wNTdmSwmDtIrFAphdQa9G+phcjfaaZAt5urH2SL29 zVd2kj0gnFz9RTigNuZERuHAApEki2GWuUo0YLDu0EnURB6rTTvdhi4ol 5A4852uaWcwnp624WGwZ9Y/DJHqbl9s9QJmbBWJ+Dd00HrDwx9XQunLgQ 9dHWs1eruLzIFsdwbwFBdzGFrBDe87L290KeyJ9ATZwsDNKCcy5arfbt0 g==; X-CSE-ConnectionGUID: eI0b1W5nQTWyERZIVq9ZoQ== X-CSE-MsgGUID: P2m6ZU5bSVqCXTe77y90NA== X-IronPort-AV: E=McAfee;i="6800,10657,11728"; a="85246631" X-IronPort-AV: E=Sophos;i="6.23,118,1770624000"; d="scan'208";a="85246631" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2026 12:25:39 -0700 X-CSE-ConnectionGUID: lKzKFj+IT4+or4fS2K8AIw== X-CSE-MsgGUID: 5BGhgcfwRhOJUywABz/zQg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,118,1770624000"; d="scan'208";a="259152581" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa001.jf.intel.com with ESMTP; 13 Mar 2026 12:25:39 -0700 From: Sohil Mehta To: Dave Hansen , x86@kernel.org, Andy Lutomirski , Borislav Petkov , "H . Peter Anvin" Cc: Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Sohil Mehta , Nam Cao , Cedric Xing , Rick Edgecombe , Andrew Cooper , Michael Roth , Brijesh Singh , Jarkko Sakkinen , Tony Luck , linux-kernel@vger.kernel.org Subject: [RFC PATCH 2/2] x86/vsyscall: Avoid vsyscall emulation for some unexpected fault types Date: Fri, 13 Mar 2026 12:23:27 -0700 Message-ID: <20260313192327.2089471-3-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260313192327.2089471-1-sohil.mehta@intel.com> References: <20260313192327.2089471-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" Currently, vsyscall emulation is rejected for write faults and kernel-privilege faults. Other page fault error codes such as X86_PF_PK and X86_PF_SHSTK are unlikely to be set in the vsyscall context. However, it is good to explicitly reject them from a defensive point of view. So, avoid vsyscall emulation if X86_PF_PK or X86_PF_SHSTK is set. Note, X86_PF_RSVD is already handled in do_user_addr_fault() before vsyscall emulation is attempted. Suggested-by: H. Peter Anvin (Intel) Signed-off-by: Sohil Mehta --- arch/x86/entry/vsyscall/vsyscall_64.c | 5 +++-- arch/x86/mm/fault.c | 3 --- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index b1f8f8a57b02..bf0ae314a0fb 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -257,8 +257,9 @@ static bool __emulate_vsyscall(struct pt_regs *regs, un= signed long address) 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) + /* Only simple user read faults get fixed up (no write, PK or shadow stac= k). */ + if ((error_code & (X86_PF_WRITE | X86_PF_PK | X86_PF_SHSTK | X86_PF_USER)= ) !=3D + X86_PF_USER) return false; =20 /* diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index f0e77e084482..004b242ebbf8 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1309,9 +1309,6 @@ void do_user_addr_fault(struct pt_regs *regs, * * The vsyscall page does not have a "real" VMA, so do this * emulation before we go searching for VMAs. - * - * PKRU never rejects instruction fetches, so we don't need - * to consider the PF_PK bit. */ if (is_vsyscall_vaddr(address)) { if (emulate_vsyscall_pf(error_code, regs, address)) --=20 2.43.0