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: <20160111182243.GF18367@kernel.org>
Date:	Mon, 11 Jan 2016 15:22:43 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Stephane Eranian <eranian@...gle.com>,
	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

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.

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.

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.

- Arnaldo