[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: stack bounds
From: |
Bruno Haible |
Subject: |
Re: stack bounds |
Date: |
Sat, 10 Oct 2020 23:49:04 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; ) |
Paul Eggert wrote:
> > On Linux, the kernel allows the stack to grow by any amount, if it does not
> > become closer than 1 MB to another VMA and does not violate the set limits.
> > See linux/mm/mmap.c:expand_downwards and linux/mm/mmap.c:acct_stack_growth.
> > Therefore on Linux, there is no need for a guard page and no need for
> > 'gcc -fstack-clash-protection'.
>
> There's still a need, if a function declares a large local variable, as the
> stack pointer can jump around the 1 MB barrier and trash other storage. If I
> compile the attached program with 'gcc -m32 -O2 stackish.c' on Fedora 31
> x86-64,
> the program exits with status 255 (instead of crashing with a stack overflow
> as
> it should), because the stack has overflowed and has stomped on the heap. So
> stack overflow checking is not "just working", at least for this particular
> case.
Oh, I see: your program is not getting near the heap with the stack, it is
getting directly *into* the heap (because it fills the bottom of array 'b'
without having filled the rest of 'b' first).
gcc -fstack-clash-protection -m32 -O2 stackish.c fixes this issue.
So, you want 'gcc -fstack-clash-protection' [1] to become enabled by default?
Some distros are doing this already:
- Ubuntu 20.04 [2] (also -fstack-clash-protection is part of the default
gcc flags for users),
- RHEL 8 [1] (but apparently not by default for user-compiled programs),
and the Firefox people are considering it [3].
Bruno
[1]
https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gcc-part-3/
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040741.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1588710
stackish.s.ubuntu
Description: Text document