linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Sun, 12 Nov 2017 13:39:44 +0900	[thread overview]
Message-ID: <720b01a7-05bc-22d8-fdb1-1d67a0e18b54@marcan.st> (raw)
In-Reply-To: <CALCETrV-Q817-woi=2GqP4t46yTHF+p301C6ObFn2NDXeqfukw@mail.gmail.com>

On 2017-11-12 13:21, Andy Lutomirski wrote:
>> 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).
> 
> If you're generating code to improve stack overflow, assuming that you
> have at least two pages left seems like an *awful* assumption to make.

If all the code is compiled with the option, then it guarantees you have
at least two pages left, as long as you have at least two pages when the
program/thread starts.

> Gentoo Hardened should seriously consider turning it back off.  Do you
> happen to know what exactly Gentoo does to cause the vdso to get build
> with -fstack-check?  I'll write a patch to either fail the build or to
> force it off.

So you're saying Gentoo Hardened should turn off an exploit mitigation
that, though imperfect, works in the vast majority of cases and seems to
have caused a grand total of one [1] bug in a package so far (two if you
count the one I found)? That seems completely silly to me. I'm sure once
GCC 8 is out with dedicated stack clash protection they'll switch to
that, but in the meantime -fstack-check seems like a perfectly
reasonable idea.

Anyway, they just add it to the default specs for gcc. You can turn it
back off with -fstack-check=no.

You still haven't addressed the important question, though: should vDSO
be *documented* to consume a certain maximum amount of stack space? If
not, this whole thing is pointless since vDSO would be fine as it is. If
yes, then -fstack-check=no isn't the only thing you have to worry about;
more options to limit stack frame size, and perhaps code changes to
inline everything, might be appropriate.

[1] https://bugs.gentoo.org/637152

-- 
Hector Martin "marcan" (marcan@marcan.st)
Public Key: https://mrcn.st/pub

  reply	other threads:[~2017-11-12  4:39 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' [this message]
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=720b01a7-05bc-22d8-fdb1-1d67a0e18b54@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).