From mboxrd@z Thu Jan 1 00:00:00 1970 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 7CD193B5820 for ; Fri, 13 Mar 2026 19:25:38 +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=1773429940; cv=none; b=E7Uk6FhtJI7HCACFYM9YW5WtHFxkfz++3TItETB8r2BxH/h9kdKOC4M5F1tpck2u4h3UW/i/ZVkBRMcbqfMzzbjHCqh53K19ea9Y719x8dljIj2aGdyLhREdfXAtaGmigWR6VZNY4gxPeoOrQ28/pixzmkRJ5mdzHTJb9LQHVq8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773429940; c=relaxed/simple; bh=WmWvokEkg6yzMk4r/s8dadgDtSIHLB/N0VkpnOTwE8Q=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=XFX2zFC46g+3IG21higmWVkrrT+RAAs5Wr47zpGwT6QG6v1vwVWdGUdZBtkPTZcqRMZcRwKPvGcTREzOE/3E3gpPm31gE/fic1AscwlGxp6dA17iOClQuxdMu3IVuE5/qsRKYz8ZIhZoMtB62I0tK2DC38Yo4PbeMX9Qlo+UEns= 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=R6b5o/q/; 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="R6b5o/q/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1773429939; x=1804965939; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=WmWvokEkg6yzMk4r/s8dadgDtSIHLB/N0VkpnOTwE8Q=; b=R6b5o/q/RDo6TAFRek1DXUgzO9r8h4Hu+rC3dVDkZaCIxrGt7par2p8x 46Hjm8jn4qopUCQ9Wf0sODujrDKgFDQHNfYK0Ogyv7XpVqQfpOfl19F01 EXMd6QSp+jBpsgrCAL+T6VBW6BL8wBzUg/M3j5VtnoR0scmouXfEQeD3f ujdvhweLcv2ERXGeSCE4aDajF/Ixu2PTijXeqfjesjRs9W4AZ47ZMv52J 6GLjPYe9SnBWQpdQEUr0potxMNLse/0G7ew2S+dPJliysQAcQU8BSfw2T tDA2fhnkiFO0kStB18JCQ57yRwogTG2h7ZV9lXaKRm2G9OjPeUacfXHry Q==; X-CSE-ConnectionGUID: gkM6jc8KQEy0WPPP7WwUYg== X-CSE-MsgGUID: 2PkQafBUT5iOK1ItPMtl1Q== X-IronPort-AV: E=McAfee;i="6800,10657,11728"; a="85246611" X-IronPort-AV: E=Sophos;i="6.23,118,1770624000"; d="scan'208";a="85246611" 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:38 -0700 X-CSE-ConnectionGUID: 4OrtuKRZSqaDMmZKLzHBwQ== X-CSE-MsgGUID: 6BN3FpgyR6+gzziv2B3Gcg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,118,1770624000"; d="scan'208";a="259152570" Received: from sohilmeh.sc.intel.com ([172.25.103.65]) by orviesa001.jf.intel.com with ESMTP; 13 Mar 2026 12:25:37 -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 0/2] x86/vsyscall: Tighten vsyscall emulation checks for a #PF fixup Date: Fri, 13 Mar 2026 12:23:25 -0700 Message-ID: <20260313192327.2089471-1-sohil.mehta@intel.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series is a result of the suggestions made by Peter Anvin at https://lore.kernel.org/lkml/2074c00d-2e73-4bd9-89d2-7b0a015b134e@zytor.com/. The vsyscall emulation code already has a bunch of checks to make sure only valid page faults get emulated. This series improves those checks mainly from the defensive point of view. The patches are based on the LASS-vsyscall series under review at https://lore.kernel.org/lkml/20260309181029.398498-1-sohil.mehta@intel.com/ Patch 1 seems like a straightforward change that is unlikely to cause any issues. Patch 2 adds a few more PF error codes to the emulation reject-list. But, it is debatable whether they are absolutely necessary. X86_PF_RSVD: Reserved bits being set in do_user_addr_fault() already generates an OOPS before vsyscall emulation attempted. No need to check for it again. X86_PF_PK: PKRU never rejects instruction fetches so it is highly unlikely the vsyscall emulation code will be reached with this bit set. X86_PF_SHSTK: I am not sure if we can have a vsyscall page access that results in X86_PF_SHSTK set but doesn't have X86_PF_WRITE with it. If we cannot, the current checks in emulate_vsyscall_pf() will already reject emulation. I have included X86_PF_PK and X86_PF_SHSTK in patch 2 because I am not a 100% sure about the reasoning. Additionally, I don't see any harm in including them. Also, should we also add X86_PF_SGX and X86_PF_RMP by the same logic? Any insight here would be appreciated. The patches pass the vsyscall selftest. But, they should be considered untested as I don't know how to generate these PF error codes in the vsyscall context. Sohil Mehta (2): x86/vsyscall: Avoid vsyscall emulation when X86_PF_INSTR is not set x86/vsyscall: Avoid vsyscall emulation for some unexpected fault types arch/x86/entry/vsyscall/vsyscall_64.c | 10 ++++++---- arch/x86/mm/fault.c | 3 --- 2 files changed, 6 insertions(+), 7 deletions(-) -- 2.43.0