linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
@ 2018-11-02 19:40 Waiman Long
  2018-11-02 19:44 ` Dave Hansen
  0 siblings, 1 reply; 12+ messages in thread
From: Waiman Long @ 2018-11-02 19:40 UTC (permalink / raw)
  To: Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov
  Cc: H. Peter Anvin, x86, linux-kernel, Waiman Long

The current x86 page fault handler allows stack access below the stack
pointer if it is no more than 64k+256 bytes. Any access beyond the 64k+
limit will cause a segmentation fault.

The gcc -fstack-check option generates code to probe the stack for
large stack allocation to see if the stack is accessible. The newer gcc
does that while updating the %rsp simultaneously. Older gcc's like gcc4
doesn't do that. As a result, an application compiled with an old gcc
and the -fstack-check option may fail to start at all.

% cat test.c
int main() {
	char tmp[1024*128];
	printf("### ok\n");
	return 0;
}
% gcc -fstack-check -g -o test test.c
% ./test
Segmentation fault

The 64k+ limit check is kind of arbitrary. So the check is now removed
to just let expand_stack() decide if a segmentation fault should happen.

Signed-off-by: Waiman Long <longman@redhat.com>
---
 arch/x86/mm/fault.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 71d4b9d..29525cf 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1380,18 +1380,6 @@ void do_user_addr_fault(struct pt_regs *regs,
 		bad_area(regs, sw_error_code, address);
 		return;
 	}
-	if (sw_error_code & X86_PF_USER) {
-		/*
-		 * Accessing the stack below %sp is always a bug.
-		 * The large cushion allows instructions like enter
-		 * and pusha to work. ("enter $65535, $31" pushes
-		 * 32 pointers and then decrements %sp by 65535.)
-		 */
-		if (unlikely(address + 65536 + 32 * sizeof(unsigned long) < regs->sp)) {
-			bad_area(regs, sw_error_code, address);
-			return;
-		}
-	}
 	if (unlikely(expand_stack(vma, address))) {
 		bad_area(regs, sw_error_code, address);
 		return;
-- 
1.8.3.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-02 19:40 [RFC PATCH] x86/mm/fault: Allow stack access below %rsp Waiman Long
@ 2018-11-02 19:44 ` Dave Hansen
  2018-11-02 19:50   ` Waiman Long
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Hansen @ 2018-11-02 19:44 UTC (permalink / raw)
  To: Waiman Long, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov
  Cc: H. Peter Anvin, x86, linux-kernel

On 11/2/18 12:40 PM, Waiman Long wrote:
> The 64k+ limit check is kind of arbitrary. So the check is now removed
> to just let expand_stack() decide if a segmentation fault should happen.

With the 64k check removed, what's the next limit that we bump into?  Is
it just the stack_guard_gap space above the next-lowest VMA?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-02 19:44 ` Dave Hansen
@ 2018-11-02 19:50   ` Waiman Long
  2018-11-02 20:11     ` Andy Lutomirski
  2018-11-02 22:28     ` Dave Hansen
  0 siblings, 2 replies; 12+ messages in thread
From: Waiman Long @ 2018-11-02 19:50 UTC (permalink / raw)
  To: Dave Hansen, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov
  Cc: H. Peter Anvin, x86, linux-kernel

On 11/02/2018 03:44 PM, Dave Hansen wrote:
> On 11/2/18 12:40 PM, Waiman Long wrote:
>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>> to just let expand_stack() decide if a segmentation fault should happen.
> With the 64k check removed, what's the next limit that we bump into?  Is
> it just the stack_guard_gap space above the next-lowest VMA?

I think it is both the stack_guard_gap space above the next lowest VMA
and the rlimit(RLIMIT_STACK).

Cheers,
Longman


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-02 19:50   ` Waiman Long
@ 2018-11-02 20:11     ` Andy Lutomirski
  2018-11-02 20:34       ` Waiman Long
  2018-11-02 22:28     ` Dave Hansen
  1 sibling, 1 reply; 12+ messages in thread
From: Andy Lutomirski @ 2018-11-02 20:11 UTC (permalink / raw)
  To: Waiman Long
  Cc: Dave Hansen, Dave Hansen, Andrew Lutomirski, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
	X86 ML, LKML

On Fri, Nov 2, 2018 at 12:50 PM Waiman Long <longman@redhat.com> wrote:
>
> On 11/02/2018 03:44 PM, Dave Hansen wrote:
> > On 11/2/18 12:40 PM, Waiman Long wrote:
> >> The 64k+ limit check is kind of arbitrary. So the check is now removed
> >> to just let expand_stack() decide if a segmentation fault should happen.
> > With the 64k check removed, what's the next limit that we bump into?  Is
> > it just the stack_guard_gap space above the next-lowest VMA?
>
> I think it is both the stack_guard_gap space above the next lowest VMA
> and the rlimit(RLIMIT_STACK).
>

Did the non-working programs ever work?  Because, if not, I say let them fail.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-02 20:11     ` Andy Lutomirski
@ 2018-11-02 20:34       ` Waiman Long
  0 siblings, 0 replies; 12+ messages in thread
From: Waiman Long @ 2018-11-02 20:34 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Dave Hansen, Dave Hansen, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, H. Peter Anvin, X86 ML, LKML

On 11/02/2018 04:11 PM, Andy Lutomirski wrote:
> On Fri, Nov 2, 2018 at 12:50 PM Waiman Long <longman@redhat.com> wrote:
>> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>>> On 11/2/18 12:40 PM, Waiman Long wrote:
>>>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>>>> to just let expand_stack() decide if a segmentation fault should happen.
>>> With the 64k check removed, what's the next limit that we bump into?  Is
>>> it just the stack_guard_gap space above the next-lowest VMA?
>> I think it is both the stack_guard_gap space above the next lowest VMA
>> and the rlimit(RLIMIT_STACK).
>>
> Did the non-working programs ever work?  Because, if not, I say let them fail.

The program was working before on older kernel. After the backport of
the commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas"),
the program stopped working. I believe it is the removal of the
check_stack_guard_page() function which did expand the stack. So the 64k
check was actually not functional because of the stack expansion before
hand, but now it does.

Anyway, I see the current 64k check a very crude check on an userspace
error. I think there are quite a number of more powerful userspace tools
out there that can do this kind of check more effectively. Kernel isn't
the right place to do that.

Cheers,
Longman



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-02 19:50   ` Waiman Long
  2018-11-02 20:11     ` Andy Lutomirski
@ 2018-11-02 22:28     ` Dave Hansen
  2018-11-05  5:11       ` Andy Lutomirski
  2018-11-05 16:27       ` Waiman Long
  1 sibling, 2 replies; 12+ messages in thread
From: Dave Hansen @ 2018-11-02 22:28 UTC (permalink / raw)
  To: Waiman Long, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov
  Cc: H. Peter Anvin, x86, linux-kernel

On 11/2/18 12:50 PM, Waiman Long wrote:
> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>> On 11/2/18 12:40 PM, Waiman Long wrote:
>>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>>> to just let expand_stack() decide if a segmentation fault should happen.
>> With the 64k check removed, what's the next limit that we bump into?  Is
>> it just the stack_guard_gap space above the next-lowest VMA?
> I think it is both the stack_guard_gap space above the next lowest VMA
> and the rlimit(RLIMIT_STACK).

The gap seems to be hundreds of megabytes, typically where RLIMIT_STACK
is 8MB by default, so RLIMIT_STACK is likely to be the practical limit
that will be hit.  So, practically, we've taken a ~64k area that we
would on-demand extend the stack into in one go, and turned that into a
the full ~8MB area that you could have expanded into anyway, but all at
once.

That doesn't seem too insane, especially since we don't physically back
the 8MB or anything.  Logically, it also seems like you *should* be able
to touch any bit of the stack within the rlimit.

But, on the other hand, as our comments say: "Accessing the stack below
%sp is always a bug."  Have we been unsuccessful in convincing our gcc
buddies of this?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-02 22:28     ` Dave Hansen
@ 2018-11-05  5:11       ` Andy Lutomirski
  2018-11-05  5:14         ` Andy Lutomirski
  2018-11-05 16:27       ` Waiman Long
  1 sibling, 1 reply; 12+ messages in thread
From: Andy Lutomirski @ 2018-11-05  5:11 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Waiman Long, Dave Hansen, Andrew Lutomirski, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
	X86 ML, LKML

On Fri, Nov 2, 2018 at 3:28 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 11/2/18 12:50 PM, Waiman Long wrote:
> > On 11/02/2018 03:44 PM, Dave Hansen wrote:
> >> On 11/2/18 12:40 PM, Waiman Long wrote:
> >>> The 64k+ limit check is kind of arbitrary. So the check is now removed
> >>> to just let expand_stack() decide if a segmentation fault should happen.
> >> With the 64k check removed, what's the next limit that we bump into?  Is
> >> it just the stack_guard_gap space above the next-lowest VMA?
> > I think it is both the stack_guard_gap space above the next lowest VMA
> > and the rlimit(RLIMIT_STACK).
>
> The gap seems to be hundreds of megabytes, typically where RLIMIT_STACK
> is 8MB by default, so RLIMIT_STACK is likely to be the practical limit
> that will be hit.  So, practically, we've taken a ~64k area that we
> would on-demand extend the stack into in one go, and turned that into a
> the full ~8MB area that you could have expanded into anyway, but all at
> once.
>
> That doesn't seem too insane, especially since we don't physically back
> the 8MB or anything.  Logically, it also seems like you *should* be able
> to touch any bit of the stack within the rlimit.
>
> But, on the other hand, as our comments say: "Accessing the stack below
> %sp is always a bug."  Have we been unsuccessful in convincing our gcc
> buddies of this?

FWIW, the old code is a bit bogus.  Why are we restricting the range
of stack expending addresses for user code without restricting the
range of kernel uaccess addresses that would do the same thing?

So I think I agree with the patch.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-05  5:11       ` Andy Lutomirski
@ 2018-11-05  5:14         ` Andy Lutomirski
  2018-11-05 17:20           ` Dave Hansen
  0 siblings, 1 reply; 12+ messages in thread
From: Andy Lutomirski @ 2018-11-05  5:14 UTC (permalink / raw)
  To: Andrew Lutomirski
  Cc: Dave Hansen, Waiman Long, Dave Hansen, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
	X86 ML, LKML

On Sun, Nov 4, 2018 at 9:11 PM Andy Lutomirski <luto@kernel.org> wrote:
>
> On Fri, Nov 2, 2018 at 3:28 PM Dave Hansen <dave.hansen@intel.com> wrote:
> >
> > On 11/2/18 12:50 PM, Waiman Long wrote:
> > > On 11/02/2018 03:44 PM, Dave Hansen wrote:
> > >> On 11/2/18 12:40 PM, Waiman Long wrote:
> > >>> The 64k+ limit check is kind of arbitrary. So the check is now removed
> > >>> to just let expand_stack() decide if a segmentation fault should happen.
> > >> With the 64k check removed, what's the next limit that we bump into?  Is
> > >> it just the stack_guard_gap space above the next-lowest VMA?
> > > I think it is both the stack_guard_gap space above the next lowest VMA
> > > and the rlimit(RLIMIT_STACK).
> >
> > The gap seems to be hundreds of megabytes, typically where RLIMIT_STACK
> > is 8MB by default, so RLIMIT_STACK is likely to be the practical limit
> > that will be hit.  So, practically, we've taken a ~64k area that we
> > would on-demand extend the stack into in one go, and turned that into a
> > the full ~8MB area that you could have expanded into anyway, but all at
> > once.
> >
> > That doesn't seem too insane, especially since we don't physically back
> > the 8MB or anything.  Logically, it also seems like you *should* be able
> > to touch any bit of the stack within the rlimit.
> >
> > But, on the other hand, as our comments say: "Accessing the stack below
> > %sp is always a bug."  Have we been unsuccessful in convincing our gcc
> > buddies of this?
>
> FWIW, the old code is a bit bogus.  Why are we restricting the range
> of stack expending addresses for user code without restricting the
> range of kernel uaccess addresses that would do the same thing?
>
> So I think I agree with the patch.

I should add: if this patch is *not* applied, then I think we'll need
to replace the sw_error_code check with user_mode(regs) to avoid an
info leak if CET is enabled.  Because, with CET, WRUSS will allow a
*kernel* mode access (where regs->sp is the kernel stack pointer) with
user permissions.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-02 22:28     ` Dave Hansen
  2018-11-05  5:11       ` Andy Lutomirski
@ 2018-11-05 16:27       ` Waiman Long
  2018-11-05 17:51         ` Dave Hansen
  1 sibling, 1 reply; 12+ messages in thread
From: Waiman Long @ 2018-11-05 16:27 UTC (permalink / raw)
  To: Dave Hansen, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov
  Cc: H. Peter Anvin, x86, linux-kernel

On 11/02/2018 06:28 PM, Dave Hansen wrote:
> On 11/2/18 12:50 PM, Waiman Long wrote:
>> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>>> On 11/2/18 12:40 PM, Waiman Long wrote:
>>>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>>>> to just let expand_stack() decide if a segmentation fault should happen.
>>> With the 64k check removed, what's the next limit that we bump into?  Is
>>> it just the stack_guard_gap space above the next-lowest VMA?
>> I think it is both the stack_guard_gap space above the next lowest VMA
>> and the rlimit(RLIMIT_STACK).
> The gap seems to be hundreds of megabytes, typically where RLIMIT_STACK
> is 8MB by default, so RLIMIT_STACK is likely to be the practical limit
> that will be hit.  So, practically, we've taken a ~64k area that we
> would on-demand extend the stack into in one go, and turned that into a
> the full ~8MB area that you could have expanded into anyway, but all at
> once.
>
> That doesn't seem too insane, especially since we don't physically back
> the 8MB or anything.  Logically, it also seems like you *should* be able
> to touch any bit of the stack within the rlimit.
>
> But, on the other hand, as our comments say: "Accessing the stack below
> %sp is always a bug."  Have we been unsuccessful in convincing our gcc
> buddies of this?

With gcc 4.4.7, the object code for the sample program in the commit log
are:

  0x00000000004004c4 <+0>:    push   %rbp
   0x00000000004004c5 <+1>:    mov    %rsp,%rbp
   0x00000000004004c8 <+4>:    push   %rbx
   0x00000000004004c9 <+5>:    sub    $0x18,%rsp
   0x00000000004004cd <+9>:    lea    -0x2ff8(%rsp),%rax
   0x00000000004004d5 <+17>:    movq   $0x0,(%rax)
   0x00000000004004dc <+24>:    mov    %rsp,%rax
   0x00000000004004df <+27>:    mov    %rax,%rbx
   0x00000000004004e2 <+30>:    lea    -0x3ff8(%rsp),%rax
   0x00000000004004ea <+38>:    lea    -0x43008(%rsp),%rdx
   0x00000000004004f2 <+46>:    jmp    0x400501 <main+61>
   0x00000000004004f4 <+48>:    movq   $0x0,(%rax)
   0x00000000004004fb <+55>:    sub    $0x1000,%rax
   0x0000000000400501 <+61>:    cmp    %rdx,%rax
   0x0000000000400504 <+64>:    ja     0x4004f4 <main+48>
   0x0000000000400506 <+66>:    movq   $0x0,(%rdx)
   0x000000000040050d <+73>:    sub    $0x40010,%rsp
   0x0000000000400514 <+80>:    mov    %rsp,%rax
   0x0000000000400517 <+83>:    add    $0xf,%rax
   0x000000000040051b <+87>:    shr    $0x4,%rax
   0x000000000040051f <+91>:    shl    $0x4,%rax
   0x0000000000400523 <+95>:    mov    %rax,-0x18(%rbp)
   0x0000000000400527 <+99>:    mov    $0x400638,%edi
   0x000000000040052c <+104>:    callq  0x4003b8 <puts@plt>
   0x0000000000400531 <+109>:    mov    $0x0,%eax
   0x0000000000400536 <+114>:    mov    %rbx,%rsp
   0x0000000000400539 <+117>:    mov    -0x8(%rbp),%rbx
   0x000000000040053d <+121>:    leaveq
   0x000000000040053e <+122>:    retq  

With a newer gcc 4.8.5, the object code becomes

   0x000000000040052d <+0>:    push   %rbp
   0x000000000040052e <+1>:    mov    %rsp,%rbp
   0x0000000000400531 <+4>:    lea    -0x1020(%rsp),%rsp
   0x0000000000400539 <+12>:    mov    $0xfffffffffffc0000,%r11
   0x0000000000400540 <+19>:    lea    (%rsp,%r11,1),%r11
   0x0000000000400544 <+23>:    cmp    %r11,%rsp
   0x0000000000400547 <+26>:    je     0x400557 <main+42>
   0x0000000000400549 <+28>:    sub    $0x1000,%rsp
   0x0000000000400550 <+35>:    orq    $0x0,(%rsp)
   0x0000000000400555 <+40>:    jmp    0x400544 <main+23>
   0x0000000000400557 <+42>:    lea    0x1020(%rsp),%rsp
   0x000000000040055f <+50>:    mov    $0x400600,%edi
   0x0000000000400564 <+55>:    callq  0x400410 <puts@plt>
   0x0000000000400569 <+60>:    mov    $0x0,%eax
   0x000000000040056e <+65>:    leaveq
   0x000000000040056f <+66>:    retq   

So gcc had changed to avoid doing that, but my main concern are old
binaries that were compiled with old gcc.

Cheers,
Longman




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-05  5:14         ` Andy Lutomirski
@ 2018-11-05 17:20           ` Dave Hansen
  2018-11-05 19:21             ` Andy Lutomirski
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Hansen @ 2018-11-05 17:20 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Waiman Long, Dave Hansen, Peter Zijlstra, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, H. Peter Anvin, X86 ML, LKML


On 11/4/18 9:14 PM, Andy Lutomirski wrote:
> I should add: if this patch is *not* applied, then I think we'll
> need to replace the sw_error_code check with user_mode(regs) to avoid
> an info leak if CET is enabled.  Because, with CET, WRUSS will allow
> a *kernel* mode access (where regs->sp is the kernel stack pointer)
> with user permissions.

Are you saying that WRUSS, if it faults will set the "user" page fault
error code bit?  I seem to have some rough recollection about it being
that way, and the shadow-stack spec does say:

	paging access control checks will be treated as a user-mode
	shadow stack store

But the SDM says:

	For all instruction fetches and most data accesses, this
	distinction is determined by the current privilege level (CPL):
	accesses made while CPL < 3 are supervisor-mode accesses, while
	accesses made while CPL = 3 are user-mode accesses.

It would certainly be ideal if things affecting the core architecture
like this were in the SDM itself before we merged them.  It makes things
like this a lot easier to figure out.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-05 16:27       ` Waiman Long
@ 2018-11-05 17:51         ` Dave Hansen
  0 siblings, 0 replies; 12+ messages in thread
From: Dave Hansen @ 2018-11-05 17:51 UTC (permalink / raw)
  To: Waiman Long, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov
  Cc: H. Peter Anvin, x86, linux-kernel

On 11/5/18 8:27 AM, Waiman Long wrote:
> So gcc had changed to avoid doing that, but my main concern are old
> binaries that were compiled with old gcc.

Yeah, fair enough.

FWIW, I don't have any strong feelings about this patch either way, but
supporting old binaries/compilers without crashing seems fairly
important.  I'm yet to see any major downsides to your patch.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
  2018-11-05 17:20           ` Dave Hansen
@ 2018-11-05 19:21             ` Andy Lutomirski
  0 siblings, 0 replies; 12+ messages in thread
From: Andy Lutomirski @ 2018-11-05 19:21 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Andrew Lutomirski, Waiman Long, Dave Hansen, Peter Zijlstra,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
	X86 ML, LKML

On Mon, Nov 5, 2018 at 9:20 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
>
> On 11/4/18 9:14 PM, Andy Lutomirski wrote:
> > I should add: if this patch is *not* applied, then I think we'll
> > need to replace the sw_error_code check with user_mode(regs) to avoid
> > an info leak if CET is enabled.  Because, with CET, WRUSS will allow
> > a *kernel* mode access (where regs->sp is the kernel stack pointer)
> > with user permissions.
>
> Are you saying that WRUSS, if it faults will set the "user" page fault
> error code bit?  I seem to have some rough recollection about it being
> that way, and the shadow-stack spec does say:
>
>         paging access control checks will be treated as a user-mode
>         shadow stack store
>

I believe so, and it would make sense for it to work this way.  I
would love some instructions for directly accessing normal user
memory, too.  Maybe a prefix?

> But the SDM says:
>
>         For all instruction fetches and most data accesses, this
>         distinction is determined by the current privilege level (CPL):
>         accesses made while CPL < 3 are supervisor-mode accesses, while
>         accesses made while CPL = 3 are user-mode accesses.
>
> It would certainly be ideal if things affecting the core architecture
> like this were in the SDM itself before we merged them.  It makes things
> like this a lot easier to figure out.

Agreed.  The current documentation situation is not so good.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2018-11-05 19:22 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-02 19:40 [RFC PATCH] x86/mm/fault: Allow stack access below %rsp Waiman Long
2018-11-02 19:44 ` Dave Hansen
2018-11-02 19:50   ` Waiman Long
2018-11-02 20:11     ` Andy Lutomirski
2018-11-02 20:34       ` Waiman Long
2018-11-02 22:28     ` Dave Hansen
2018-11-05  5:11       ` Andy Lutomirski
2018-11-05  5:14         ` Andy Lutomirski
2018-11-05 17:20           ` Dave Hansen
2018-11-05 19:21             ` Andy Lutomirski
2018-11-05 16:27       ` Waiman Long
2018-11-05 17:51         ` Dave Hansen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).