i386 ABI and the stack

i386 ABI and the stack

[Albert Cahalan]

I just saw git commit 21528454f6dd18231ae20102f98aa8f51b6ec1b9
go in with this:

+ * Accessing the stack below %esp is always a bug.
+ * The large cushion allows instructions like enter
+ * and pusha to work. ("enter $65535,$31" pushes
+ * 32 pointers and then decrements %esp by 65535.)

Exactly how is an access below %esp a bug if we just added support?
It looks like we now have a 65664-byte red zone on i386, and probably
on x86-64 once the matching patch goes in. (the space reserved by
signal handlers may differ, though perhaps it should not)

This is water under the bridge anyway, because of gcc 2.xx.x bugs.

It seems that we're throwing away performance if we discourage
the compiler from taking advantage of this area to optimize
leaf functions and perhaps improve instruction scheduling.

Re: i386 ABI and the stack

[Linus Torvalds]

On Fri, 23 Jun 2006, Albert Cahalan wrote:
> 
> Exactly how is an access below %esp a bug if we just added support?

It's always a bug on x86.

Signal handlers will overwrite the stack, so if you use the stack before 
decrementing the stack pointer, you're fundamentally screwed.

The "enter" (and "pusha" etc) instructions are special and magical, 
because they _will_ decrement the stack pointer atomically if they 
succeed.

> It seems that we're throwing away performance if we discourage
> the compiler from taking advantage of this area to optimize
> leaf functions and perhaps improve instruction scheduling.

We always have. It's the x86 ABI.

The x86-64 ABI has a 128-byte(*) zone that is safe from signals etc, so 
you can use a small amount of stack below the stackpointer safely. Not so 
on x86.

		Linus

(*) That "128 byte" is from memory. Maybe it's bigger.

Re: i386 ABI and the stack

[H. Peter Anvin]

Albert Cahalan wrote:
> I just saw git commit 21528454f6dd18231ae20102f98aa8f51b6ec1b9
> go in with this:
> 
> + * Accessing the stack below %esp is always a bug.
> + * The large cushion allows instructions like enter
> + * and pusha to work. ("enter $65535,$31" pushes
> + * 32 pointers and then decrements %esp by 65535.)
> 
> Exactly how is an access below %esp a bug if we just added support?
> It looks like we now have a 65664-byte red zone on i386, and probably
> on x86-64 once the matching patch goes in. (the space reserved by
> signal handlers may differ, though perhaps it should not)

No, we don't.  The enter instruction is special because it *atomically* 
drops the stack and probes the stack pointer; if the instruction fails, 
then the stack pointer is rolled back, which is why the kernel needs to 
be aware of it.

We could add a redzone to i386 (and then get compilers to know about 
it), but we haven't already done so.  The difference is that we'd have 
to adjust the stack pointer before writing a signal stack frame. 
However, libc probably needs to be aware of this, because this zone 
needs to also be reserved for every stack in a threaded program.

> This is water under the bridge anyway, because of gcc 2.xx.x bugs.
> 
> It seems that we're throwing away performance if we discourage
> the compiler from taking advantage of this area to optimize
> leaf functions and perhaps improve instruction scheduling.

Probably, although likely not much; x86 processors tend to need to 
optimize push/pop anyway.  However, as x86-64 shows, having a small 
redzone might be worth it.

	-hpa

Re: i386 ABI and the stack

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> We always have. It's the x86 ABI.
> 
> The x86-64 ABI has a 128-byte(*) zone that is safe from signals etc, so 
> you can use a small amount of stack below the stackpointer safely. Not so 
> on x86.
> 
> 		Linus
> 
> (*) That "128 byte" is from memory. Maybe it's bigger.

Adding a small redzone like this to i386 would be easy, though -- just 
drop the stack pointer by that much when creating a signal frame.  128 
bytes isn't enough to interfere with libraries.

Unlike other enhancements that have been proposed to the i386 ABI (like 
regparm), this has the advantage of being fully backwards-compatible 
with old binaries and libraries.  As long as you have a kernel that 
knows to preserve the redzone, then you can use the new -mredzone 
option, but you cross-call classical ABI functions without any problems, 
and old ABI programs won't even notice.

	-hpa

Re: i386 ABI and the stack

[Linus Torvalds]

On Fri, 23 Jun 2006, H. Peter Anvin wrote:
> > 
> > The x86-64 ABI has a 128-byte(*) zone that is safe from signals etc, so you
> > can use a small amount of stack below the stackpointer safely. Not so on
> > x86.
> 
> Adding a small redzone like this to i386 would be easy, though -- just drop
> the stack pointer by that much when creating a signal frame.  128 bytes isn't
> enough to interfere with libraries.

However, any binaries created with that in mind would be 
buggy-by-definition on older kernels, so I don't think it's worth it. 

> Unlike other enhancements that have been proposed to the i386 ABI (like
> regparm), this has the advantage of being fully backwards-compatible with old
> binaries and libraries.

Right, but it's not backwards-compatible with old kernels ;(

So any user space app that does it would have to be pretty crazy.

I don't think it's a huge advantage anyway. x86 CPU's are really good at 
tracking %esp - there are papers out there that talk about how %esp is the 
limiter for effective IPC, but modern x86 CPU's will generally have ways 
around it, so in _practice_ I think you can do

	subl $16,%esp
	movl %eax,4(%esp)

without having any address stall on the subtract on most modern CPU cores 
(because the core will break the dependency and track %esp specially).

That's the Yonah "stack engine", afaik. And I could obviously name other 
CPU's that does it too, but I probably shouldn't ;)

		Linus

Re: i386 ABI and the stack

[Albert Cahalan]

On 6/23/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Fri, 23 Jun 2006, H. Peter Anvin wrote:
> > >
> > > The x86-64 ABI has a 128-byte(*) zone that is safe from signals etc, so you
> > > can use a small amount of stack below the stackpointer safely. Not so on
> > > x86.
> >
> > Adding a small redzone like this to i386 would be easy, though -- just drop
> > the stack pointer by that much when creating a signal frame.  128 bytes isn't
> > enough to interfere with libraries.
>
> However, any binaries created with that in mind would be
> buggy-by-definition on older kernels, so I don't think it's worth it.

Since gcc-2.96 would access 256 bytes below the stack pointer
(according to the valgrind man page), the kernel needs to allow
for this in signal handlers anyway.

I'm pretty sure I saw that code in the kernel in fact, but I
can't find it now. Perhaps it got lost in a cleanup accident?
(it sure would be nice to have continuous source control history)

Re: i386 ABI and the stack

[H. Peter Anvin]

Albert Cahalan wrote:
> Since gcc-2.96 would access 256 bytes below the stack pointer
> (according to the valgrind man page), the kernel needs to allow
> for this in signal handlers anyway.
> 
> I'm pretty sure I saw that code in the kernel in fact, but I
> can't find it now. Perhaps it got lost in a cleanup accident?
> (it sure would be nice to have continuous source control history)

We have it; you can graft on the pre-git history.  See previous posts on 
this and the git list.

	-hpa

Re: i386 ABI and the stack

[Arjan van de Ven]

On Fri, 2006-06-23 at 22:43 -0400, Albert Cahalan wrote:
> On 6/23/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > On Fri, 23 Jun 2006, H. Peter Anvin wrote:
> > > >
> > > > The x86-64 ABI has a 128-byte(*) zone that is safe from signals etc, so you
> > > > can use a small amount of stack below the stackpointer safely. Not so on
> > > > x86.
> > >
> > > Adding a small redzone like this to i386 would be easy, though -- just drop
> > > the stack pointer by that much when creating a signal frame.  128 bytes isn't
> > > enough to interfere with libraries.
> >
> > However, any binaries created with that in mind would be
> > buggy-by-definition on older kernels, so I don't think it's worth it.
> 
> Since gcc-2.96 would access 256 bytes below the stack pointer
> (according to the valgrind man page), the kernel needs to allow
> for this in signal handlers anyway.

only a handful buggy editions of that compiler did in a few corner
cases. And they were really buggy, and they were corner cases. Nobody
should be using a compiler like that; and nobody is expected to compile
software with a broken version of that compiler (iirc the window in
which it was broken was really small). There is a limit to userspace
brokenness that the kernel should work around. This imo is on the other
side of the line.