Separate out the actual vsyscall emulation from the #PF specific
handling in preparation for the upcoming #GP emulation.
No functional change intended.
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
v10:
- Modify the code flow slightly to make it easier to follow.
---
arch/x86/entry/vsyscall/vsyscall_64.c | 63 ++++++++++++++-------------
arch/x86/include/asm/vsyscall.h | 7 ++-
arch/x86/mm/fault.c | 2 +-
3 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index 6e6c0a740837..4c3f49bf39e6 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -112,43 +112,13 @@ static bool write_ok_or_segv(unsigned long ptr, size_t size)
}
}
-bool emulate_vsyscall(unsigned long error_code,
- struct pt_regs *regs, unsigned long address)
+static bool __emulate_vsyscall(struct pt_regs *regs, unsigned long address)
{
unsigned long caller;
int vsyscall_nr, syscall_nr, tmp;
long ret;
unsigned long orig_dx;
- /* Write faults or kernel-privilege faults never get fixed up. */
- if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER)
- return false;
-
- /*
- * Assume that faults at regs->ip are because of an
- * instruction fetch. Return early and avoid
- * emulation for faults during data accesses:
- */
- if (address != regs->ip) {
- /* Failed vsyscall read */
- if (vsyscall_mode == EMULATE)
- return false;
-
- /*
- * User code tried and failed to read the vsyscall page.
- */
- warn_bad_vsyscall(KERN_INFO, regs, "vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround");
- return false;
- }
-
- /*
- * X86_PF_INSTR is only set when NX is supported. When
- * 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));
-
/*
* No point in checking CS -- the only way to get here is a user mode
* trap to a high address, which means that we're in 64-bit user code.
@@ -281,6 +251,37 @@ bool emulate_vsyscall(unsigned long error_code,
return true;
}
+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)
+ return false;
+
+ /*
+ * Assume that faults at regs->ip are because of an instruction
+ * fetch. Return early and avoid emulation for faults during
+ * data accesses:
+ */
+ if (address != regs->ip) {
+ /* User code tried and failed to read the vsyscall page. */
+ if (vsyscall_mode != EMULATE)
+ warn_bad_vsyscall(KERN_INFO, regs, "vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround");
+
+ return false;
+ }
+
+ /*
+ * X86_PF_INSTR is only set when NX is supported. When
+ * 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));
+
+ return __emulate_vsyscall(regs, address);
+}
+
/*
* A pseudo VMA to allow ptrace access for the vsyscall page. This only
* covers the 64bit vsyscall page now. 32bit has a real VMA now and does
diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h
index 472f0263dbc6..f34902364972 100644
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -14,12 +14,11 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root);
* Called on instruction fetch fault in vsyscall page.
* Returns true if handled.
*/
-extern bool emulate_vsyscall(unsigned long error_code,
- struct pt_regs *regs, unsigned long address);
+bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, unsigned long address);
#else
static inline void map_vsyscall(void) {}
-static inline bool emulate_vsyscall(unsigned long error_code,
- struct pt_regs *regs, unsigned long address)
+static inline bool emulate_vsyscall_pf(unsigned long error_code,
+ struct pt_regs *regs, unsigned long address)
{
return false;
}
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 998bd807fc7b..fbcc2da75fd6 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1316,7 +1316,7 @@ void do_user_addr_fault(struct pt_regs *regs,
* to consider the PF_PK bit.
*/
if (is_vsyscall_vaddr(address)) {
- if (emulate_vsyscall(error_code, regs, address))
+ if (emulate_vsyscall_pf(error_code, regs, address))
return;
}
#endif
--
2.43.0On Mon, 2025-10-06 at 23:51 -0700, Sohil Mehta wrote:
> Separate out the actual vsyscall emulation from the #PF specific
> handling in preparation for the upcoming #GP emulation.
>
> No functional change intended.
>
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
> ---
> v10:
> - Modify the code flow slightly to make it easier to follow.
> ---
> arch/x86/entry/vsyscall/vsyscall_64.c | 63 ++++++++++++++-------------
> arch/x86/include/asm/vsyscall.h | 7 ++-
> arch/x86/mm/fault.c | 2 +-
> 3 files changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
> index 6e6c0a740837..4c3f49bf39e6 100644
> --- a/arch/x86/entry/vsyscall/vsyscall_64.c
> +++ b/arch/x86/entry/vsyscall/vsyscall_64.c
> @@ -112,43 +112,13 @@ static bool write_ok_or_segv(unsigned long ptr, size_t size)
> }
> }
>
> -bool emulate_vsyscall(unsigned long error_code,
> - struct pt_regs *regs, unsigned long address)
> +static bool __emulate_vsyscall(struct pt_regs *regs, unsigned long address)
> {
> unsigned long caller;
> int vsyscall_nr, syscall_nr, tmp;
> long ret;
> unsigned long orig_dx;
>
> - /* Write faults or kernel-privilege faults never get fixed up. */
> - if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER)
> - return false;
> -
> - /*
> - * Assume that faults at regs->ip are because of an
> - * instruction fetch. Return early and avoid
> - * emulation for faults during data accesses:
> - */
> - if (address != regs->ip) {
> - /* Failed vsyscall read */
> - if (vsyscall_mode == EMULATE)
> - return false;
> -
> - /*
> - * User code tried and failed to read the vsyscall page.
> - */
> - warn_bad_vsyscall(KERN_INFO, regs, "vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround");
> - return false;
> - }
> -
> - /*
> - * X86_PF_INSTR is only set when NX is supported. When
> - * 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));
> -
> /*
> * No point in checking CS -- the only way to get here is a user mode
> * trap to a high address, which means that we're in 64-bit user code.
I don't know. Is this as true any more? We are now sometimes guessing based on
regs->ip of a #GP. What if the kernel accidentally tries to jump to the vsyscall
address? Then we are reading the kernel stack and strange things. Maybe it's
worth replacing the comment with a check? Feel free to call this paranoid.
> @@ -281,6 +251,37 @@ bool emulate_vsyscall(unsigned long error_code,
> return true;
> }
>
> +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)
> + return false;
> +
> + /*
> + * Assume that faults at regs->ip are because of an instruction
> + * fetch. Return early and avoid emulation for faults during
> + * data accesses:
> + */
> + if (address != regs->ip) {
> + /* User code tried and failed to read the vsyscall page. */
> + if (vsyscall_mode != EMULATE)
> + warn_bad_vsyscall(KERN_INFO, regs, "vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround");
> +
> + return false;
> + }
> +
> + /*
> + * X86_PF_INSTR is only set when NX is supported. When
> + * 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));
> +
> + return __emulate_vsyscall(regs, address);
> +}
> +
> /*
> * A pseudo VMA to allow ptrace access for the vsyscall page. This only
> * covers the 64bit vsyscall page now. 32bit has a real VMA now and does
> diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h
> index 472f0263dbc6..f34902364972 100644
> --- a/arch/x86/include/asm/vsyscall.h
> +++ b/arch/x86/include/asm/vsyscall.h
> @@ -14,12 +14,11 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root);
> * Called on instruction fetch fault in vsyscall page.
> * Returns true if handled.
> */
> -extern bool emulate_vsyscall(unsigned long error_code,
> - struct pt_regs *regs, unsigned long address);
> +bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, unsigned long address);
> #else
> static inline void map_vsyscall(void) {}
> -static inline bool emulate_vsyscall(unsigned long error_code,
> - struct pt_regs *regs, unsigned long address)
> +static inline bool emulate_vsyscall_pf(unsigned long error_code,
> + struct pt_regs *regs, unsigned long address)
> {
> return false;
> }
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 998bd807fc7b..fbcc2da75fd6 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1316,7 +1316,7 @@ void do_user_addr_fault(struct pt_regs *regs,
> * to consider the PF_PK bit.
> */
> if (is_vsyscall_vaddr(address)) {
> - if (emulate_vsyscall(error_code, regs, address))
> + if (emulate_vsyscall_pf(error_code, regs, address))
> return;
> }
> #endif
On 10/7/25 11:37, Edgecombe, Rick P wrote:
>> /*
>> * No point in checking CS -- the only way to get here is a user mode
>> * trap to a high address, which means that we're in 64-bit user code.
> I don't know. Is this as true any more? We are now sometimes guessing based on
> regs->ip of a #GP. What if the kernel accidentally tries to jump to the vsyscall
> address? Then we are reading the kernel stack and strange things. Maybe it's
> worth replacing the comment with a check? Feel free to call this paranoid.
The first check in emulate_vsyscall() is:
/* Write faults or kernel-privilege faults never get fixed up. */
if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER)
return false;
If the kernel jumped to the vsyscall page, it would end up there, return
false, and never reach the code near the "No point in checking CS" comment.
Right? Or am I misunderstanding the scenario you're calling out?
If I'm understanding it right, I'd be a bit reluctant to add a CS check
as well.
On Tue, Oct 7, 2025, at 11:48 AM, Dave Hansen wrote: > On 10/7/25 11:37, Edgecombe, Rick P wrote: >>> /* >>> * No point in checking CS -- the only way to get here is a user mode >>> * trap to a high address, which means that we're in 64-bit user code. >> I don't know. Is this as true any more? We are now sometimes guessing based on >> regs->ip of a #GP. What if the kernel accidentally tries to jump to the vsyscall >> address? Then we are reading the kernel stack and strange things. Maybe it's >> worth replacing the comment with a check? Feel free to call this paranoid. > > The first check in emulate_vsyscall() is: > > /* Write faults or kernel-privilege faults never get fixed up. */ > if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER) > return false; > > If the kernel jumped to the vsyscall page, it would end up there, return > false, and never reach the code near the "No point in checking CS" comment. > > Right? Or am I misunderstanding the scenario you're calling out? > > If I'm understanding it right, I'd be a bit reluctant to add a CS check > as well. IMO it should boil down to exactly the same thing as the current code for the #PF case and, for #GP, there are two logical conditions that we care about: 1. Are we in user mode? 2. Are we using a 64-bit CS such that vsyscall emulation makes sense. Now I'd be a tiny bit surprised if a CPU allows you to lretq or similar to a 32-bit CS with >2^63 RIP, but what do I know? One could test this on a variety of machines, both Intel and AMD, to see what actually happens. But the kernel wraps all this up as user_64bit_mode(regs). If user_64bit_mode(regs) is true and RIP points to a vsyscall, then ISTM there aren't a whole lot of options. Somehow we're in user mode, either via an exit from kernel mode or via CALL/JMP/whatever from user mode, and RIP is pointing at the vsyscall page, and CS is such that, in the absence of LASS, we would execute the vsyscall. I suppose the #GP could be from some other cause than a LASS violation, but that doesn't seem worth worrying about. So I think all that's needed is to update "[PATCH v10 10/15] x86/vsyscall: Add vsyscall emulation for #GP" to check user_64bit_mode(regs) for the vsyscall case. (As submitted, unless I missed something while composing the patches in my head, it's only checking user_mode(regs), and I think it's worth the single extra line of code to make the result a tiny bit more robust.)
Thank you for taking a look at these patches. On 10/30/2025 9:58 AM, Andy Lutomirski wrote: > So I think all that's needed is to update "[PATCH v10 10/15] x86/vsyscall: Add vsyscall emulation for #GP" to check user_64bit_mode(regs) for the vsyscall case. (As submitted, unless I missed something while composing the patches in my head, it's only checking user_mode(regs), and I think it's worth the single extra line of code to make the result a tiny bit more robust.) I probably don't understand all the nuances here. But, the goal of the check seems to ensure a 32-bit process running on a 64-bit kernel doesn't ever go through this vsyscall emulation code, right? I guess a user_64bit_mode(regs) check wouldn't harm. I'll add it when the vsyscall series is posted.
On Thu, 30 Oct 2025 12:28:52 -0700 Sohil Mehta <sohil.mehta@intel.com> wrote: > Thank you for taking a look at these patches. > > On 10/30/2025 9:58 AM, Andy Lutomirski wrote: > > > So I think all that's needed is to update "[PATCH v10 10/15] x86/vsyscall: Add vsyscall emulation for #GP" to check user_64bit_mode(regs) for the vsyscall case. (As submitted, unless I missed something while composing the patches in my head, it's only checking user_mode(regs), and I think it's worth the single extra line of code to make the result a tiny bit more robust.) > > I probably don't understand all the nuances here. But, the goal of the > check seems to ensure a 32-bit process running on a 64-bit kernel > doesn't ever go through this vsyscall emulation code, right? Do remember that there is no such thing as a '32-bit process'. Changing to/from 'long mode' isn't privileged. OTOH in 32-bit mode you can't generate an address above 4G. (But I've no idea if the high register bits get cleared before the register is modified.) David > > I guess a user_64bit_mode(regs) check wouldn't harm. I'll add it when > the vsyscall series is posted. > > > > >
On October 30, 2025 9:58:02 AM PDT, Andy Lutomirski <luto@kernel.org> wrote: > > >On Tue, Oct 7, 2025, at 11:48 AM, Dave Hansen wrote: >> On 10/7/25 11:37, Edgecombe, Rick P wrote: >>>> /* >>>> * No point in checking CS -- the only way to get here is a user mode >>>> * trap to a high address, which means that we're in 64-bit user code. >>> I don't know. Is this as true any more? We are now sometimes guessing based on >>> regs->ip of a #GP. What if the kernel accidentally tries to jump to the vsyscall >>> address? Then we are reading the kernel stack and strange things. Maybe it's >>> worth replacing the comment with a check? Feel free to call this paranoid. >> >> The first check in emulate_vsyscall() is: >> >> /* Write faults or kernel-privilege faults never get fixed up. */ >> if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER) >> return false; >> >> If the kernel jumped to the vsyscall page, it would end up there, return >> false, and never reach the code near the "No point in checking CS" comment. >> >> Right? Or am I misunderstanding the scenario you're calling out? >> >> If I'm understanding it right, I'd be a bit reluctant to add a CS check >> as well. > >IMO it should boil down to exactly the same thing as the current code for the #PF case and, for #GP, there are two logical conditions that we care about: > >1. Are we in user mode? > >2. Are we using a 64-bit CS such that vsyscall emulation makes sense. > >Now I'd be a tiny bit surprised if a CPU allows you to lretq or similar to a 32-bit CS with >2^63 RIP, but what do I know? One could test this on a variety of machines, both Intel and AMD, to see what actually happens. > >But the kernel wraps all this up as user_64bit_mode(regs). If user_64bit_mode(regs) is true and RIP points to a vsyscall, then ISTM there aren't a whole lot of options. Somehow we're in user mode, either via an exit from kernel mode or via CALL/JMP/whatever from user mode, and RIP is pointing at the vsyscall page, and CS is such that, in the absence of LASS, we would execute the vsyscall. I suppose the #GP could be from some other cause than a LASS violation, but that doesn't seem worth worrying about. > >So I think all that's needed is to update "[PATCH v10 10/15] x86/vsyscall: Add vsyscall emulation for #GP" to check user_64bit_mode(regs) for the vsyscall case. (As submitted, unless I missed something while composing the patches in my head, it's only checking user_mode(regs), and I think it's worth the single extra line of code to make the result a tiny bit more robust.) user_64bit_mode() is a CS check :) There is that one extra check for PARAVIRT_XXL that *could* be gotten rid of by making the PV code report its 64-bit selector and patching it into the test, but it is on the error path anyway...
On Thu, Oct 30, 2025, at 10:22 AM, H. Peter Anvin wrote: > On October 30, 2025 9:58:02 AM PDT, Andy Lutomirski <luto@kernel.org> wrote: >> >> >>On Tue, Oct 7, 2025, at 11:48 AM, Dave Hansen wrote: >>> On 10/7/25 11:37, Edgecombe, Rick P wrote: >>>>> /* >>>>> * No point in checking CS -- the only way to get here is a user mode >>>>> * trap to a high address, which means that we're in 64-bit user code. >>>> I don't know. Is this as true any more? We are now sometimes guessing based on >>>> regs->ip of a #GP. What if the kernel accidentally tries to jump to the vsyscall >>>> address? Then we are reading the kernel stack and strange things. Maybe it's >>>> worth replacing the comment with a check? Feel free to call this paranoid. >>> >>> The first check in emulate_vsyscall() is: >>> >>> /* Write faults or kernel-privilege faults never get fixed up. */ >>> if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER) >>> return false; >>> >>> If the kernel jumped to the vsyscall page, it would end up there, return >>> false, and never reach the code near the "No point in checking CS" comment. >>> >>> Right? Or am I misunderstanding the scenario you're calling out? >>> >>> If I'm understanding it right, I'd be a bit reluctant to add a CS check >>> as well. >> >>IMO it should boil down to exactly the same thing as the current code for the #PF case and, for #GP, there are two logical conditions that we care about: >> >>1. Are we in user mode? >> >>2. Are we using a 64-bit CS such that vsyscall emulation makes sense. >> >>Now I'd be a tiny bit surprised if a CPU allows you to lretq or similar to a 32-bit CS with >2^63 RIP, but what do I know? One could test this on a variety of machines, both Intel and AMD, to see what actually happens. >> >>But the kernel wraps all this up as user_64bit_mode(regs). If user_64bit_mode(regs) is true and RIP points to a vsyscall, then ISTM there aren't a whole lot of options. Somehow we're in user mode, either via an exit from kernel mode or via CALL/JMP/whatever from user mode, and RIP is pointing at the vsyscall page, and CS is such that, in the absence of LASS, we would execute the vsyscall. I suppose the #GP could be from some other cause than a LASS violation, but that doesn't seem worth worrying about. >> >>So I think all that's needed is to update "[PATCH v10 10/15] x86/vsyscall: Add vsyscall emulation for #GP" to check user_64bit_mode(regs) for the vsyscall case. (As submitted, unless I missed something while composing the patches in my head, it's only checking user_mode(regs), and I think it's worth the single extra line of code to make the result a tiny bit more robust.) > > user_64bit_mode() is a CS check :) > > There is that one extra check for PARAVIRT_XXL that *could* be gotten > rid of by making the PV code report its 64-bit selector and patching it > into the test, but it is on the error path anyway... In the hopefully unlikely event that anyone cares about #GP performance, they should probably care far, far more about the absurd PASID fix up than anything else :)
On Tue, 2025-10-07 at 11:48 -0700, Dave Hansen wrote:
> On 10/7/25 11:37, Edgecombe, Rick P wrote:
> > > /*
> > > * No point in checking CS -- the only way to get here is a user mode
> > > * trap to a high address, which means that we're in 64-bit user code.
> > I don't know. Is this as true any more? We are now sometimes guessing based on
> > regs->ip of a #GP. What if the kernel accidentally tries to jump to the vsyscall
> > address? Then we are reading the kernel stack and strange things. Maybe it's
> > worth replacing the comment with a check? Feel free to call this paranoid.
>
> The first check in emulate_vsyscall() is:
>
> /* Write faults or kernel-privilege faults never get fixed up. */
> if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER)
> return false;
>
> If the kernel jumped to the vsyscall page, it would end up there, return
> false, and never reach the code near the "No point in checking CS" comment.
>
> Right? Or am I misunderstanding the scenario you're calling out?
>
> If I'm understanding it right, I'd be a bit reluctant to add a CS check
> as well.
Sorry, I could have been clearer. Yes, I assumed that the comment was talking
about that check you quote.
But I'm looking at this applied. The following patches (which don't include that
hunk), add another call site:
bool emulate_vsyscall_gp(struct pt_regs *regs)
{
if (!cpu_feature_enabled(X86_FEATURE_LASS))
return false;
/* Emulate only if the RIP points to the vsyscall address */
if (!is_vsyscall_vaddr(regs->ip))
return false;
return __emulate_vsyscall(regs, regs->ip);
}
If indeed we should add a check, it should probably go in one of the later
patches and not this one.
On 10/7/2025 12:53 PM, Edgecombe, Rick P wrote:
> But I'm looking at this applied. The following patches (which don't include that
> hunk), add another call site:
>
> bool emulate_vsyscall_gp(struct pt_regs *regs)
> {
> if (!cpu_feature_enabled(X86_FEATURE_LASS))
> return false;
>
> /* Emulate only if the RIP points to the vsyscall address */
> if (!is_vsyscall_vaddr(regs->ip))
> return false;
>
> return __emulate_vsyscall(regs, regs->ip);
> }
>
> If indeed we should add a check, it should probably go in one of the later
> patches and not this one.
We already check CS before calling emulate_vsyscall_gp().
if (user_mode(regs)) {
...
if (emulate_vsyscall_gp(regs))
goto exit;
...
}
On Tue, 2025-10-07 at 15:52 -0700, Sohil Mehta wrote:
> >
> > If indeed we should add a check, it should probably go in one of the later
> > patches and not this one.
>
> We already check CS before calling emulate_vsyscall_gp().
>
> if (user_mode(regs)) {
>
> ...
> if (emulate_vsyscall_gp(regs))
> goto exit;
>
> ...
> }
Ah, right, I missed that. But in the new code, the way to get there is by taking
a GP with an RIP in the vsyscall range. Does this seem a bit stale though?
/*
* No point in checking CS -- the only way to get here is a user mode
* trap to a high address, which means that we're in 64-bit user code.
*/
For one, "No point in checking CS", while true kind of implies that CS wasn't
already checked. The second half I guess is still true if you call the fetch #GP
a trap, and actually maybe more accurate for LASS then it was for the older
paradigm with the "high address" verbiage.
I'm fine either way.
© 2016 - 2026 Red Hat, Inc.