All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Sohil Mehta <sohil.mehta@intel.com>
Cc: 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>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Nam Cao <namcao@linutronix.de>,
	Cedric Xing <cedric.xing@intel.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.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>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] x86/vsyscall: Avoid vsyscall emulation for unexpected page fault types
Date: Wed, 22 Jul 2026 18:36:46 +0300	[thread overview]
Message-ID: <amDjjhJS1FlyLE4X@kernel.org> (raw)
In-Reply-To: <20260722004152.503073-1-sohil.mehta@intel.com>

On Tue, Jul 21, 2026 at 05:41:51PM -0700, Sohil Mehta wrote:
> Currently, vsyscall emulation is rejected for write faults and
> kernel-privilege faults. It is assumed that other page fault error codes
> such as X86_PF_PK and X86_PF_SHSTK will not be set in the vsyscall
> context. From a defensive point of view, it is better to explicitly
> reject these faults than assume that they will never happen. So, avoid
> vsyscall emulation if any of those are present.
> 
> Note, X86_PF_SGX and X86_PF_RMP are also unlikely to occur in the
> vsyscall context. They can probably be added to the reject-list in the
> future to solidify this further. Also, X86_PF_RSVD is already handled in
> do_user_addr_fault() before vsyscall emulation is attempted.
> 
> Similarly, on systems that support X86_FEATURE_NX, X86_PF_INSTR is
> always expected to be set when an instruction fetch triggers a #PF. The
> kernel issues a warning whenever that is not the case. Instead of
> continuing when something is very wrong, return early and skip vsyscall
> emulation.
> 
> Suggested-by: H. Peter Anvin (Intel) <hpa@zytor.com>
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> ---
> v2:
>  - Combined the two patches into one.
>  - Make the commit message concise.
> 
> I have excluded SGX and RMP because I wasn't 100% sure and I didn't get
> any feedback on them in the last post. Let me know if someone wants them
> to be added.
> RFC-v1: https://lore.kernel.org/lkml/20260313192327.2089471-1-sohil.mehta@intel.com/
> ---
>  arch/x86/entry/vsyscall/vsyscall_64.c | 10 ++++++----
>  arch/x86/mm/fault.c                   |  3 ---
>  2 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
> index ea36de9fa864..5176860cef55 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, unsigned 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)) != X86_PF_USER)
> +	/* Only simple user read faults get fixed up (no write, pkey or shadow stack) */
> +	if ((error_code & (X86_PF_WRITE | X86_PF_PK | X86_PF_SHSTK | X86_PF_USER)) !=
> +	    X86_PF_USER)
>  		return false;
>  
>  	/*
> @@ -282,8 +283,9 @@ bool emulate_vsyscall_pf(unsigned long error_code, struct 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;
>  
>  	return __emulate_vsyscall(regs, address);
>  }
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 45b99c3b1442..e0b645a55844 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1318,9 +1318,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))
> -- 
> 2.43.0
> 


Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>


BR, Jarkko

      reply	other threads:[~2026-07-22 15:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22  0:41 [PATCH v2] x86/vsyscall: Avoid vsyscall emulation for unexpected page fault types Sohil Mehta
2026-07-22 15:36 ` Jarkko Sakkinen [this message]

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=amDjjhJS1FlyLE4X@kernel.org \
    --to=jarkko@kernel.org \
    --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=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=memxor@gmail.com \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=namcao@linutronix.de \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.