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 20:52:59 +0300
From:   Dmitry Safonov <dsafonov@...tuozzo.com>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     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 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

-- 
              Dmitry