linux-kernel - Re: [PATCH v2 tip/perf/core 1/6] perf symbols: find symbols in different mount namespace

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: <20170711171548.GB2570@templeofstupid.com>
Date:   Tue, 11 Jul 2017 10:15:49 -0700
From:   Krister Johansen <kjlx@...pleofstupid.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Thomas-Mich Richter <tmricht@...ux.vnet.ibm.com>,
        Brendan Gregg <brendan.d.gregg@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 tip/perf/core 1/6] perf symbols: find symbols in
 different mount namespace

On Tue, Jul 11, 2017 at 09:51:16AM -0300, Arnaldo Carvalho de Melo wrote:
> Right, we need to use the build-id and look it up in a database
> populated somehow.
> 
> perf right now, by default, collects the build-ids in a table, at the
> end of the recording session, trying not to disrupt the monitored
> workload by not processing anything, just reading from the buffers and
> dumping to a file.
> 
> It will also try to populate the build-id, trying first to make a
> hardlink and copying it if it fails.
> 
> If we can get the build-id at the time of the mmap(binary), as part of
> the loading of binaries, that would be ideal, as we're touching the file
> headers anyway and the build-id is a small enough cookie.
> 
> But again, we should first try to do as far as we can with the
> infrastructure we have in the kernel and tooling libraries, lots of
> workloads will be serviced just fine with that.

Sorry, I was slow to pick up on what you're saying here.  I agree that
getting the build-id delivered in an event from the kernel would
accelerate the process of determining whether you have or need to cache
a binary in the build-id cache.  Without such a modification, perf has
to look at each binary to determine whether the build ids match.  If we
got the build-id in the event payload, then we only need to look to see
if the build-id is cached.  If it's not, then we can undertake the more
complicated lookup path.

That would be an improvement over what we can do today.

-K