From: Andy Lutomirski <luto@kernel.org>
To: "Hector Martin 'marcan'" <marcan@marcan.st>
Cc: LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>, X86 ML <x86@kernel.org>
Subject: Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check
Date: Fri, 10 Nov 2017 14:04:08 -0800 [thread overview]
Message-ID: <CALCETrXyzt2GEHZdXTKQZo6t08oA4wSwuooA2G_YmPPBGJMOjg@mail.gmail.com> (raw)
In-Reply-To: <06a4b0b4-4b36-91b6-d146-9fc1300b785f@marcan.st>
> On Nov 10, 2017, at 8:02 AM, Hector Martin 'marcan' <marcan@marcan.st> 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/i386.md: ;; 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" (marcan@marcan.st)
> Public Key: https://mrcn.st/pub
prev parent reply other threads:[~2017-11-10 22:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 10:40 vDSO maximum stack usage, stack probes, and -fstack-check Hector Martin 'marcan'
2017-11-10 14:57 ` Andy Lutomirski
2017-11-10 16:02 ` [kernel-hardening] " Hector Martin 'marcan'
2017-11-10 16:36 ` Hector Martin 'marcan'
2017-11-10 22:04 ` Andy Lutomirski
2017-11-11 5:16 ` Hector Martin 'marcan'
2017-11-12 4:21 ` Andy Lutomirski
2017-11-12 4:39 ` Hector Martin 'marcan'
2017-11-10 22:04 ` Andy Lutomirski [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=CALCETrXyzt2GEHZdXTKQZo6t08oA4wSwuooA2G_YmPPBGJMOjg@mail.gmail.com \
--to=luto@kernel.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--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 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).