linux-kernel - Re: [RFC] perf record: missing buildid for callstack modules

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: <CABPqkBQpQH6ocGRBNJoPdzpLBGzdcMyR1K_keKAwTWJQoJFvtg@mail.gmail.com>
Date:	Mon, 11 Jan 2016 12:06:53 -0800
From:	Stephane Eranian <eranian@...gle.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Namhyung Kim <namhyung@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jiri Olsa <jolsa@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>
Subject: Re: [RFC] perf record: missing buildid for callstack modules

Hi,

On Mon, Jan 11, 2016 at 10:22 AM, Arnaldo Carvalho de Melo
<acme@...nel.org> wrote:
> Em Mon, Jan 11, 2016 at 06:30:36PM +0100, Peter Zijlstra escreveu:
>> On Fri, Jan 08, 2016 at 03:19:42PM -0300, Arnaldo Carvalho de Melo wrote:
>> > We already discussed how to solve it, and it involves extending once
>> > more PERF_RECORD_MMAP, so that, when we load a DSO we stash its build-id
>> > in a per-DSO data structure in the kernel, then, when generating
>> > PERF_RECORD_MMAP3 we put the buildid there, this way if any of those
>> > binaries gets replaced while we're recording samples, we would notice,
>> > i.e. we wouldn't care that much about the pathname, looking everything
>> > by the content based buildid instead.
>
>> Does the kernel even know about the buildid crap? AFAIK the binfmt stuff
>> doesn't know or care about things like that. Heck, we support binfmts
>> that do not even have a buildid.
>
It does not have to right now.

> Well, we need some cookie like that, build-id or something that allows
> us to find the right binary for doing symbol resolution, annotation,
> etc.
>
Well, you need a cookie that the kernel can have access to quickly and cheaply.
That cookie would have to be accessible to the user as well and has to be unique
per DSO. So it would have to be in the DSO headers and calculated from  known
fileds in the DSO header (which fields depends on the DSO binary
format, does not
have to be ELF). And you'd need a unique cookie -> filepath mapping.
So yeah, it would have to be in a MMAP-type record.

> And we need to do it at mmap time, i.e. we don't know upfront what DSOs
> and if we do at the end we will incur in things we also don't like:
> workload wide scanning of used DSOs, and they could've been replaced...
>
> If we do it using these build id ELF sections distros have for quite a
> while or with something else, we'd have to try and see.
>
> I.e. the MMAP3 would have whatever is in a content-based pre-calculated
> unique cookie slot, per DSO. How to populate that slot? Well, at load
> time we could get that build-id section and put there, for ELF DSOs.
>
> Or we could generate that at load time and later recalculate when
> looking for the DSO to match what is in a perf.data file.
>
I can see clearly how to make this work for ELF + buildid. It it much harder
for formats without buildids. You'd have to have a rule between
the kernel and user tool that controls what fields in the DSO and used
to compute
the hash. Buildid are at most 20 bytes IIRC. So any hash would have to
fit in these.