linux-kernel - Re: [criu] 1M guard page ruined restore

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]

Date:   Wed, 21 Jun 2017 18:24:18 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     Dmitry Safonov <dsafonov@...tuozzo.com>
cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        Hugh Dickins <hughd@...gle.com>,
        Andrey Vagin <avagin@...nvz.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Pavel Emelyanov <xemul@...tuozzo.com>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Adrian Reber <areber@...hat.com>,
        Michael Kerrisk <mtk@...7.org>
Subject: Re: [criu] 1M guard page ruined restore

On Wed, 21 Jun 2017, Dmitry Safonov wrote:
> On 06/21/2017 08:31 PM, Oleg Nesterov wrote:
> > On 06/21, Dmitry Safonov wrote:
> > > 
> > > The only question I have - how is it connected to guard page?
> > 
> > Because with stack guard page do_page_fault() almost never needs to
> > call expand_stack(), thus this check was almost never tested, I guess.
> > Probably it should go away now.
> > 
> > I'll write the changelog and patch tomorrow, unless someone does this
> > before.
> 
> Ugh, maybe it's also worth now to update man 2 mmap.
> 
> At this moment, mmap() will no more return address one page lower
> and "guard" is no more a page:
> 
> > MAP_GROWSDOWN
> >        This flag is used for stacks. It indicates to the kernel virtual
> >        memory system that the mapping should extend downward in
> >        memory. The return address is one page lower than the memory
> >        area that is actually created in the process's virtual address
> >        space. Touching an address in the "guard" page below the mapping
> >        will cause the mapping to grow by a page. This growth can be
> >        repeated until the mapping grows to within a page of the high end
> >        of the next lower mapping, at which point touching the "guard"
> >        page will result in a  SIGSEGV signal.
> 
> CC'ing Michael

That does go into rather more detail than I like to see: I suppose
the man pages on my machines are rather old, and only show the first
two innocuous sentences about MAP_GROWSDOWN.

Michael, v4.12-rc6 enlarges the stack guard gap from one page to 256
pages (by default).  But quite what the man page ought to say will
depend on the outcome of the discussion in the lkp-robot thread.
(Or perhaps it isn't a discussion, but me feeling over-anxious
about how Linus has decided.)  Maybe the robot will settle it.

Hugh