linux-kernel - Re: [PATCH] mm: larger stack guard gap, between vmas

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrW5P8ZhuOJ4bL0x+hx52RdFkG4_x0qAQofrdBi2JavxmA@mail.gmail.com>
Date:   Wed, 5 Jul 2017 09:15:20 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Ben Hutchings <ben@...adent.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Willy Tarreau <w@....eu>, Hugh Dickins <hughd@...gle.com>,
        Oleg Nesterov <oleg@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...hat.com>,
        Larry Woodman <lwoodman@...hat.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Tony Luck <tony.luck@...el.com>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Helge Diller <deller@....de>,
        James Hogan <james.hogan@...tec.com>,
        Laura Abbott <labbott@...hat.com>, Greg KH <greg@...ah.com>,
        "security@...nel.org" <security@...nel.org>,
        linux-distros@...openwall.org,
        Qualys Security Advisory <qsa@...lys.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ximin Luo <infinity0@...ian.org>
Subject: Re: [PATCH] mm: larger stack guard gap, between vmas

On Wed, Jul 5, 2017 at 7:23 AM, Michal Hocko <mhocko@...nel.org> wrote:
> On Wed 05-07-17 13:19:40, Ben Hutchings wrote:
>> On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote:
>> > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings <ben@...adent.org.uk>
>> > wrote:
>> > >
>> > > We have:
>> > >
>> > > bottom = 0xff803fff
>> > > sp =     0xffffb178
>> > >
>> > > The relevant mappings are:
>> > >
>> > > ff7fc000-ff7fd000 rwxp 00000000 00:00 0
>> > > fffdd000-ffffe000 rw-p 00000000 00:00
>> > > 0                                  [stack]
>> >
>> > Ugh. So that stack is actually 8MB in size, but the alloca() is about
>> > to use up almost all of it, and there's only about 28kB left between
>> > "bottom" and that 'rwx' mapping.
>> >
>> > Still, that rwx mapping is interesting: it is a single page, and it
>> > really is almost exactly 8MB below the stack.
>> >
>> > In fact, the top of stack (at 0xffffe000) is *exactly* 8MB+4kB from
>> > the top of that odd one-page allocation (0xff7fd000).
>> >
>> > Can you find out where that is allocated? Perhaps a breakpoint on
>> > mmap, with a condition to catch that particular one?
>> [...]
>>
>> Found it, and it's now clear why only i386 is affected:
>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os/linux/vm/os_linux.cpp#l4852
>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os_cpu/linux_x86/vm/os_linux_x86.cpp#l881
>
> This is really worrying. This doesn't look like a gap at all. It is a
> mapping which actually contains a code and so we should absolutely not
> allow to scribble over it. So I am afraid the only way forward is to
> allow per process stack gap and run this particular program to have a
> smaller gap. We basically have two ways. Either /proc/<pid>/$file or
> a prctl inherited on exec. The later is a smaller code. What do you
> think?

Why inherit on exec?

I think that, if we add a new API, we should do it right rather than
making it even more hackish.  Specifically, we'd add a real VMA type
(via flag or whatever) that means "this is a modern stack".  A modern
stack wouldn't ever expand and would have no guard page at all.  It
would, however, properly account stack space by tracking the pages
used as stack space.  Users of the new VMA type would be responsible
for allocating their own guard pages, probably by mapping an extra
page and than mapping PROT_NONE over it.

Also, this doesn't even need a new API, I think.  What's wrong with
plain old mmap(2) with MAP_STACK and *without* MAP_GROWSDOWN?  Only
new kernels would get the accounting right, but I doubt that matters
much in practice.