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:   Tue, 20 Jun 2017 14:10:18 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Hugh Dickins <hughd@...gle.com>, Andrey Vagin <avagin@...nvz.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Pavel Emelyanov <xemul@...tuozzo.com>,
        Dmitry Safonov <dsafonov@...tuozzo.com>,
        Andrew Morton <akpm@...uxfoundation.org>
Subject: Re: [criu] 1M guard page ruined restore

On Tue, Jun 20, 2017 at 12:51:16PM +0200, Oleg Nesterov wrote:
> 
> You can write a simple test. Just do mmap(MAP_GROWSDOWN) and look at
> /proc/self/maps. If it reports vm_start + PAGE_SIZE rather than addr
> returned by mmap, then the kernel is old.
> 
> > Second I guess we might need to detect @stack_guard_gap runtime as
> > well
> 
> I do not think so. criu does not need to know about the new guard area
> at all. It simply doesn't exist from user-space pov.
> 
> In fact, I think this should have been true even before this change, just
> stack_guard_page_start() was not accurate and this is the reason (I guess)
> you had to play with stack guard; the first page (hidden by show_map_vma)
> can have a valid stack data, for example if the application played with
> MAP_FIXED or munmap().
> 
> So I think you should simply disable, say, unmap_guard_pages() and most
> of all other MAP_GROWSDOWN code in criu.

Looks like a good plan. Thanks Oleg! Gonna try it.

	Cyrill