From nobody Tue Apr 7 10:38:07 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