lkml.org 
[lkml]   [2021]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] prctl: allow to setup brk for et_dyn executables
On Thu, Jan 21, 2021 at 2:12 PM Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>
> Keno Fischer reported that when a binray loaded via
> ld-linux-x the prctl(PR_SET_MM_MAP) doesn't allow to
> setup brk value because it lays before mm:end_data.
>
> For example a test program shows
>
> | # ~/t
> |
> | start_code 401000
> | end_code 401a15
> | start_stack 7ffce4577dd0
> | start_data 403e10
> | end_data 40408c
> | start_brk b5b000
> | sbrk(0) b5b000
>
> and when executed via ld-linux
>
> | # /lib64/ld-linux-x86-64.so.2 ~/t
> |
> | start_code 7fc25b0a4000
> | end_code 7fc25b0c4524
> | start_stack 7fffcc6b2400
> | start_data 7fc25b0ce4c0
> | end_data 7fc25b0cff98
> | start_brk 55555710c000
> | sbrk(0) 55555710c000
>
> This of course prevent criu from restoring such programs.
> Looking into how kernel operates with brk/start_brk inside
> brk() syscall I don't see any problem if we allow to setup
> brk/start_brk without checking for end_data. Even if someone
> pass some weird address here on a purpose then the worst
> possible result will be an unexpected unmapping of existing
> vma (own vma, since prctl works with the callers memory) but
> test for RLIMIT_DATA is still valid and a user won't be able
> to gain more memory in case of expanding VMAs via new values
> shipped with prctl call.
>
> Reported-by: Keno Fischer <keno@juliacomputing.com>
> Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Dmitry Safonov <0x7f454c46@gmail.com>
> CC: Andrey Vagin <avagin@gmail.com>

Acked-by: Andrey Vagin <avagin@gmail.com>
Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing
direct loader exec")

> CC: Kirill Tkhai <ktkhai@virtuozzo.com>
> CC: Eric W. Biederman <ebiederm@xmission.com>
> ---
> Guys, take a look please once time permit. Hopefully I didn't
> miss something 'cause made this patch via code reading only.
>
> Andrey, do we still have a criu container which tests new kernels,
> right? Would be great to run criu tests with this patch applied
> to make sure everything is intact.

Sorry for the delay. I run tests and everything works as expected.

Thanks,
Andrei

\
 
 \ /
  Last update: 2021-07-20 09:37    [W:0.072 / U:2.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site