linux-kernel - Re: perf/jit doesn't cope well with mprotect() to jit containing pages

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]

Message-ID: <CABPqkBQ05nmy==Je=YG0gP1F1yDQjzaOUY5WsQqzOE0vZ=d9DQ@mail.gmail.com>
Date:   Fri, 27 Jan 2017 09:35:59 -0800
From:   Stephane Eranian <eranian@...gle.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Andres Freund <andres@...razel.de>,
        "eranian@...il.com" <eranian@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...e.hu>,
        Anton Blanchard <anton@...abs.org>,
        Namhyung Kim <namhyung@...nel.org>
Subject: Re: perf/jit doesn't cope well with mprotect() to jit containing pages

On Fri, Jan 27, 2017 at 7:43 AM, Arnaldo Carvalho de Melo
<acme@...nel.org> wrote:
> Em Fri, Jan 27, 2017 at 02:07:02PM +0100, Peter Zijlstra escreveu:
>> Something like the (compile tested only) below might be sufficient to
>> disambiguate things. It would need a corresponding tools/perf patch of
>> course, but I'm not too familiar with that code anymore.
>
> I'm working on patch to do feature test, fallback and handling of the
> event, etc, will post later.
>
Going back to Andres' case:

T0: mmap(0x1000) anon for func1()
T1 mmap(0x2000) anon for func1();
T3: jit emits info func1() [0x0000-0x0fff]
T4: mmap(0x3000) for func2()
T5: mmap(0x4000)  for funcs2()
T6: jit emits info for func2() [0x2000-0x2fff]

So with Peter's patch, nothing will change in the flow of MMAP2 seen by perf in
this particular case. Furthermore, there is no munmap(). But now the perf tool
behavior.

Now perf detects the overlap but because it did not see an unmap(), it
will have to merge or split mmaps().

At T0 (no change from previous behavior):
0x0000-0x0fff anon

At T1 (no change = overlap):
0x0000-0x1fff anon

At T3 (no change =overlap):
0x0000-0x0fff owned by func1,
0x1000-0x1fff anon.

At T4 (change: cannot overlap non-anon range without an munmap, so
need to split):
0x0000-0x0fff owned by func1()
0x1000-0x2fff anon

At T5, (change:  cannot overlap non-anon range without an munmap, so
need to split):
0x0000-0x0fff owned by func1()
0x1000-0x3fff anon

At T6, (no change: overlapping an anon):
0x=0000-0x=0fff owned by func1()
0x1000-0x1fff anon
0x2000-0x2fff owned by func2()
0x300-0x3fff anon

In summary the key change is that an MMAP2(anon) cannot overlap an
MMAP2(file) anymore. It has to be split.
Everything else stays the same.

Do we agree?