linux-kernel - Re: [PATCH 0/2] perf: symbol offset breakage with separated debug

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: <AANLkTik8+8e6eibAUyfj+A982-jvL_kEsXNmFZ8_qom8@mail.gmail.com>
Date:	Wed, 4 Aug 2010 09:29:00 +0100
From:	Dave Martin <dave.martin@...aro.org>
To:	linux-kernel@...r.kernel.org
Cc:	Arnaldo Carvalho de Melo <acme@...hat.com>,
	kernel-team@...ts.ubuntu.com, Will Deacon <Will.Deacon@....com>,
	Linaro Dev <linaro-dev@...ts.linaro.org>
Subject: Re: [PATCH 0/2] perf: symbol offset breakage with separated debug

A follow-up on this:

On Tue, Aug 3, 2010 at 12:48 PM, Dave Martin <dave.martin@...aro.org> wrote:

[...]

>
>        a) perf represents symbols as offsets from the start of
>                the mmap'd code region which contains each
>                symbol.

I've looked at the code some more, and it looks like I've
misunderstood here.  It looks like symbol addresses are stored and
searched as _file offsets_ in relation to each mapping -- the
map__map_ip implementation bears this out, now that I understand how
it's used to translate from run-time vitrual address to a file offset:

static inline u64 map__map_ip(struct map *map, u64 ip)
{
        return ip - map->start + map->pgoff;
}

Does this conclusion look wrong to anyone?

Assuming I've understood correctly now, this means that the existing
code _is_ correct, except that seperated debug images aren't processed
correctly.

This means that my patch "work around incorrect ET_EXEC symbol
adjustment" is therefore a bodge, not a fix -- it will "work" in many
cases, for the reasons previously discussed, but it's probably not the
right solution.

Looks like I need to think about this a bit more--- basically we need
to have the ELF section or program headers from the each mmap'd file
available in order to translate correctly between file offset and
link-time virtual address for each image.  The information would need
to be available either when loading symbols or when doing symbol
lookups.  As already discussed, the headers from separated debug
images are junk (at least the p_offset and sh_offset values are junk)
and will lead to wrong address calculations.

We could
    a) Capture the relevant information during perf record, in
addition to capturing the build-ids.  This might break the perf data
file format, but has the advantage (?) that perf report can display
correct image-relative virtual addresses even if the debug symbols
can't be loaded.  map__map_ip could be converted to output
    b) Try to read the loadable image _and_ the debug image during
perf report.  Currently the code only loads one image per mapping.
Loading both and cross-referencing information between them would make
the loading process more complicated.

For (a) we know the program headers will be correct, since they can be
obtained from the exact file that was mapped during the profiling run.
For (b) the "real" file may have gone, and we search other locations
instead.  So, we would need a way to detect which set of program
headers are the correct ones when we search for images to load.  I'm
not sure what the best approach is for this -- maybe some checks for
empty PT_LOAD segments (i.e., for which p_filesz == 0, or is much
smaller than p_memsz) would work...

Any views welcome on which approach would be best.

Cheers
---Dave
--
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/