From: "Hector Martin 'marcan'" <marcan@marcan.st>
To: Andy Lutomirski <luto@kernel.org>
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: Sat, 11 Nov 2017 14:16:48 +0900 [thread overview]
Message-ID: <6dc150cb-13df-65d8-cb6e-0a522c13ae11@marcan.st> (raw)
In-Reply-To: <CALCETrVd-f-N=O6QmtdzS7oSVkXpsJhxH+=9+0fvfFmy5Cz3WQ@mail.gmail.com>
On 2017-11-11 07:04, Andy Lutomirski wrote:
>> On Nov 10, 2017, at 8:36 AM, Hector Martin 'marcan' <marcan@marcan.st> wrote:
>>
>>> On 2017-11-11 01:02, Hector Martin 'marcan' wrote:
>>> Not entirely sure what's going on here.
>>
>> Actually, if you think about it, it doesn't matter that it skips the
>> first page, since it's probing one page more. That just means the caller
>> will have probed the previous page. So ultimately you're just probing
>> ahead of where you need to, but that should be OK.
>>
>
> The whole point is to touch the stack pages in order. Also, I see no
> guarantee that the function would touch the intermediate page before
> clobbering the probed page. You're seeing exactly that behavior, in
> fact.
Only because Go is not C and is not compiled like this. If all the code
is GCC-compiled C code and built with -fstack-check, it should always
probe stack pages in order except for potentially the second page in the
stack, which may be touched after the third page (but hopefully your
stack is at least two pages long to begin with).
AIUI -fstack-check was not intended for stack clash protection (the
latter isn't even in a GCC release yet), but in most circumstances it
seems to me like it's an effective mitigation if all code is compiled
with it. Qualys mentioned it as such in their advisory. This is probably
why Gentoo Hardened enables it by default globally in their toolchain.
--
Hector Martin "marcan" (marcan@marcan.st)
Public Key: https://mrcn.st/pub
next prev parent reply other threads:[~2017-11-11 5:16 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' [this message]
2017-11-12 4:21 ` Andy Lutomirski
2017-11-12 4:39 ` Hector Martin 'marcan'
2017-11-10 22:04 ` Andy Lutomirski
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=6dc150cb-13df-65d8-cb6e-0a522c13ae11@marcan.st \
--to=marcan@marcan.st \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--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).