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