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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 22 Jun 2017 11:06:28 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     Dmitry Safonov <dsafonov@...tuozzo.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.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, Jun 21, 2017 at 06:24:18PM -0700, Hugh Dickins wrote:
> > 
> > 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.

On my fedora24 too :) And I rather wonder why guard page is mentioned
here, because as far as I remember the only "cut off a guard page"
case was proc/$pid/[s]maps output. mmap() returned exact vma's start
address all the time, isn't it? Where the guard page is rather an
internal kernel's handling of page faults for growsdown areas.

> 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.

	Cyrill