linux-kernel - Re: [PATCH V2 9/9] perf buildid-cache: Check relocation when checking for existing kcore

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]

Date:	Thu, 30 Jan 2014 11:18:21 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Adrian Hunter <adrian.hunter@...el.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jiri Olsa <jolsa@...hat.com>, Mike Galbraith <efault@....de>,
	Namhyung Kim <namhyung@...il.com>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH V2 9/9] perf buildid-cache: Check relocation when
 checking for existing kcore

Em Thu, Jan 30, 2014 at 11:34:38AM +0200, Adrian Hunter escreveu:
> On 29/01/14 21:14, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Jan 29, 2014 at 04:14:44PM +0200, Adrian Hunter escreveu:
> >> perf buildid-cache does not make another
> >> copy of kcore if the buildid and modules
> >> match an existing copy.  That does not

> > Humm, what is the problem? Having the ref reloc symbol we can fix things
> > up, no? I.e. just using map->reloc the old kcore copy should be ok to
> > use, no need to replace the kcore copy in the cache. Or am I missing
> > something?

> The current implementation works on the basis that kcore matches the
> perf data recorded.  This is just a fix for that.

> I am afraid it is that way because it meets my needs.

> I did not think of allowing for relocation because I need to be able
> to walk the code.  Relocation was one of the things I was trying to
> avoid.

> For me making a copy of kcore is far superior because it can be made
> to have the jump labels mostly the right way around too. e.g. run a
> dummy perf record while making the copy.

Yes, it is superior, no question about it, I'm just trying to figure out
how this fits into the build-id cache thing, i.e. it should have files
keyed by its build-id, that are inserted, but not replaced, since it
expects its contents to be constant.

So you have a need to get the matching kcore at the time you did the
record, because we're dealing with self modifying code, the kernel (soon
if not already, userspace as well)...

So at least we need to make this abundantly clear to users, that what is
in the build-id cache may be the latest snapshot of some DSO that had a
build-id at, well, build time.

We need to add support for looking up in the binary where are places
that are modifiable and then mark those in the UI using some visual cue.

Till then, at least a paragraph in the documentation stating what
happens is needed, I'll look into it.

And then right now this is just for kcore, that is clearly marked as
such in the build-id cache, IIRC it is in a separate directory, etc,
right?

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/