linux-kernel - Re: [PATCH 1/2] perf: Add munmap callback

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: <c7356e5d-71e2-1562-1a0b-2ca0d985d4cb@linux.intel.com>
Date:   Thu, 1 Nov 2018 10:09:35 -0400
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Stephane Eranian <eranian@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 1/2] perf: Add munmap callback

On 10/24/2018 3:30 PM, Stephane Eranian wrote:
> The need for this new record type extends beyond physical address conversions
> and PEBS. A long while ago, someone reported issues with symbolization related
> to perf lacking munmap tracking. It had to do with vma merging. I think the
> sequence of mmaps was as follows in the problematic case:
> 1.   addr1 = mmap(8192);
> 2.   munmap(addr1 + 4096, 4096)
> 3.   addr2 = mmap(addr1+4096, 4096)
> 
> If successful, that yields addr2 = addr1 + 4096 (could also get the
> same without forcing the address).
> 
> In that case, if I recall correctly, the vma for 1st mapping (now at
> 4k) and that of the 2nd mapping (4k)
> get merged into a single 8k vma and this is what perf_events will
> record for PERF_RECORD_MMAP.
> On the perf tool side, it is assumed that if two timestamped mappings
> overlap then, the latter overrides
> the former. In this case, perf would loose the mapping of the first
> 4kb and assume all symbols comes from
> 2nd mapping. Hopefully I got the scenario right. If so, then you'd
> need PERF_RECORD_UNMAP to
> disambiguate assuming the perf tool is modified accordingly.
> 

Hi Stephane and Peter,

I went through the link(https://lkml.org/lkml/2017/1/27/452). I'm trying 
to understand the problematic case.

It looks like the issue can only be triggered by perf inject --jit. 
Because it can inject extra MMAP events.
As my understanding,  Linux kernel only try to merge VMAs if they are 
both from anon or they are both from the same file. --jit breaks the 
rule, and makes the merged VMA partly from anon, partly from file.
Now, there is a new MMAP event which range covers the modified VMA.
Without the help of MUNMAP event, perf tool have no idea if the new one 
is a newly merged VMA (modified VMA + a new VMA) or a brand new VMA.
Current code just simply overwrite the modified VMAs. The VMA 
information which --jit injected may be lost. The symbolization may be 
lost as well.

Except --jit, the VMAs information should be consistent between kernel 
and perf tools. We shouldn't observe the problem. MUNMAP event is not 
needed.

Is my understanding correct?

Do you have a test case for the problem?

Thanks,
Kan