mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sohil Mehta <sohil.mehta@intel.com>
To: Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, Andy Lutomirski <luto@kernel.org>,
	Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Sohil Mehta <sohil.mehta@intel.com>,
	Nam Cao <namcao@linutronix.de>,
	Cedric Xing <cedric.xing@intel.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michael Roth <michael.roth@amd.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	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	[thread overview]
Message-ID: <20260313192327.2089471-1-sohil.mehta@intel.com> (raw)

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


             reply	other threads:[~2026-03-13 19:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13 19:23 Sohil Mehta [this message]
2026-03-13 19:23 ` [RFC PATCH 1/2] x86/vsyscall: Avoid vsyscall emulation when X86_PF_INSTR is not set Sohil Mehta
2026-03-13 19:23 ` [RFC PATCH 2/2] x86/vsyscall: Avoid vsyscall emulation for some unexpected fault types Sohil Mehta
2026-03-18 18:47 ` [RFC PATCH 0/2] x86/vsyscall: Tighten vsyscall emulation checks for a #PF fixup Edgecombe, Rick P
2026-03-18 18:47 ` Edgecombe, Rick P
2026-03-19 18:30   ` Sohil Mehta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260313192327.2089471-1-sohil.mehta@intel.com \
    --to=sohil.mehta@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=cedric.xing@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=namcao@linutronix.de \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®