Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 10 Nov 2017 14:04:08 -0800
From: Andy Lutomirski <>
To: "Hector Martin 'marcan'" <>
Cc: LKML <>, 
	"" <>, X86 ML <>
Subject: Re: Re: vDSO maximum stack usage, stack probes,
 and -fstack-check

> On Nov 10, 2017, at 8:02 AM, Hector Martin 'marcan' <> wrote:
>> On 2017-11-10 23:57, Andy Lutomirski wrote:
>> This code is so wrong I don't even no where to start.  Seriously, sub,
>> orq, add?  How about just orq with an offset?  How about a *load*
>> instead of a store?
> Stores should be cheaper than loads (since they don't stall), but
> apparently the rationale for using orq is:

I'm having trouble imagining a CPU that would stall on an unused load
but would not stall on an RMW.

> gcc/config/i386/ ;; Use IOR for stack probes, this is shorter.
> Saves bytes I guess? Though being read-modify-write it probably hurts
> performance; I don't know what real CPUs would do with it.
> I suspect the sub, add is there to guarantee that the stack pointer is
> actually below the probed location. IIRC the x86-64 ABI specifies a
> 128-byte redzone that you can freely mess with; going beyond that would
> require actually changing the stack pointer.

The redzone says that signals won't clobber the first 128 bytes.  For
a stack probe, no one cares about the value at the probed address, so
this seems moot.  Maybe there's some kernel that would object to the
sort-of-out-of-bounds probe, but that seems unlikely.

>> But stepping back even further, an offset > 4096 is just bogus.
>> That's big enough to skip right over the guard page.
> The code (gcc/config/i386/i386.c) says:
>  /* We skip the probe for the first interval + a small dope of 4 words
>     and probe that many bytes past the specified size to maintain a
>     protection area at the botton of the stack.  */
> Not entirely sure what's going on here.
> OTOH I'm not sure why it's probing at all, since AIUI it only needs to
> probe for stack frames >4k to begin with.
>> Anyway, my recollection is that GCC's stack check code is busted until
>> much newer gcc versions.  I suppose we could try to make the kernel
>> fail to build at all on a broken configuration like this.
> Well, the original point still stands. Even if what GCC is doing is
> stupid here, it's not illegal (it's just eating stack space), and the
> kernel still currently makes no guarantees about that. So I think the
> conversation regarding vDSO stack usage guarantees is still worth having.
> --
> Hector Martin "marcan" (
> Public Key:

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.