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 12:51:16 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     Cyrill Gorcunov <gorcunov@...il.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 06/20, Cyrill Gorcunov wrote:
>
>  | diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>  | index f0c8b33..520802d 100644
>  | --- a/fs/proc/task_mmu.c
>  | +++ b/fs/proc/task_mmu.c
>  | @@ -300,11 +300,7 @@ show_map_vma(struct seq_file *m, struct vm_area_struct *vma, int is_pid)
>  |
>  |         /* We don't show the stack guard page in /proc/maps */
>  |         start = vma->vm_start;
>  | -       if (stack_guard_page_start(vma, start))
>  | -               start += PAGE_SIZE;
>  |         end = vma->vm_end;
>  | -       if (stack_guard_page_end(vma, end))
>  | -               end -= PAGE_SIZE;
>  |
>  |         seq_setwidth(m, 25 + sizeof(void *) * 6 - 1);
>  |         seq_printf(m, "%08lx-%08lx %c%c%c%c %08llx %02x:%02x %lu ",
>
> For which we of course are not ready because we've been implying the
> guard page is returned here so we adjust addresses locally when saving
> them into images.
>
> So now we need to figure out somehow if show_map_vma accounts [PAGE_SIZE|guard_area] or not,
> I guess we might use kernel version here but it won't be working fine on custom kernels,
> or kernels with the patch backported.

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.

Oleg.