From: Josh Poimboeuf <firstname.lastname@example.org>
To: Masami Hiramatsu <email@example.com>
Cc: Evgenii Shatokhin <firstname.lastname@example.org>,
Arnaldo Carvalho de Melo <email@example.com>,
Kristen Carlson Accardi <firstname.lastname@example.org>,
Peter Zijlstra <email@example.com>,
Ingo Molnar <firstname.lastname@example.org>,
Konstantin Khorenko <email@example.com>
Subject: Re: 'perf probe' and symbols from .text.<something>
Date: Tue, 23 Feb 2021 13:45:46 -0600 [thread overview]
Message-ID: <20210223194546.dhejf4mpugyw3nqq@treble> (raw)
On Tue, Feb 23, 2021 at 04:36:19PM +0900, Masami Hiramatsu wrote:
> On Tue, 23 Feb 2021 10:23:31 +0900
> Masami Hiramatsu <firstname.lastname@example.org> wrote:
> > On Mon, 22 Feb 2021 11:51:50 -0600
> > Josh Poimboeuf <email@example.com> wrote:
> > > On Tue, Feb 23, 2021 at 12:05:08AM +0900, Masami Hiramatsu wrote:
> > > > > Of course, one could place probes using absolute addresses of the
> > > > > functions but that would be less convenient.
> > > > >
> > > > > This also affects many livepatch modules where the kernel code can be
> > > > > compiled with -ffunction-sections and each function may end up in a
> > > > > separate section .text.<function_name>. 'perf probe' cannot be used
> > > > > there, except with the absolute addresses.
> > > > >
> > > > > Moreover, if FGKASLR patches are merged
> > > > > (https://lwn.net/Articles/832434/) and the kernel is built with FGKASLR
> > > > > enabled, -ffunction-sections will be used too. 'perf probe' will be
> > > > > unable to see the kernel functions then.
> > > >
> > > > Hmm, if the FGKASLAR really randomizes the symbol address, perf-probe
> > > > should give up "_text-relative" probe for that kernel, and must fallback
> > > > to the "symbol-based" probe. (Are there any way to check the FGKASLR is on?)
> > > > The problem of "symbol-based" probe is that local (static) symbols
> > > > may share a same name sometimes. In that case, it can not find correct
> > > > symbol. (Maybe I can find a candidate from its size.)
> > > > Anyway, sometimes the security and usability are trade-off.
> > >
> > > We had a similar issue with FGKASLR and live patching. The proposed
> > > solution is a new linker flag which eliminates duplicates: -z
> > > unique-symbol.
> > >
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=26391
> > Interesting, but it might not be enough for perf-probe.
> > Since the perf-probe has to handle both dwarf and elf, both must be
> > changed. I think the problem is that the dwarf is generated while
> > compiling, but this -z seems converting elf symbols in linkage.
> > As far as I can see, this appends ".COUNT" suffix to the non-unique
> > symbols in the linkage phase. Is that also applied to dwarf too?
> Ah, OK. If there is an offline elf binary with symbol map, I can convert
> DWARF symbol -> address -> offline elf symbol (unique name)-> kallsyms.
> Currently, it directly converts address by kallsyms, so I will change it
> to find elf-symbol and solve address by kallsyms in post processing.
DWARF sections have references to the ELF symbols, which are renamed by
the linker. So DWARF should automatically show the new symbol name.
And kallsyms is generated after the kernel is linked. So I'm not sure I
understand the problem.
next prev parent reply other threads:[~2021-02-23 19:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 17:09 'perf probe' and symbols from .text.<something> Evgenii Shatokhin
2021-02-18 19:35 ` Josh Poimboeuf
2021-02-22 15:05 ` Masami Hiramatsu
2021-02-22 15:12 ` Masami Hiramatsu
2021-02-22 17:51 ` Josh Poimboeuf
2021-02-23 1:23 ` Masami Hiramatsu
2021-02-23 7:36 ` Masami Hiramatsu
2021-02-23 19:45 ` Josh Poimboeuf [this message]
2021-02-24 8:00 ` Masami Hiramatsu
2021-02-23 1:48 ` [PATCH] perf-probe: Failback to symbol-base probe for probes on module Masami Hiramatsu
2021-02-23 7:36 ` Masami Hiramatsu
2021-02-23 7:09 ` 'perf probe' and symbols from .text.<something> Masami Hiramatsu
2021-02-23 7:37 ` [PATCH] perf-probe: dso: Add symbols in .text.* subsections to text symbol map in kenrel modules Masami Hiramatsu
2021-02-23 15:02 ` Evgenii Shatokhin
2021-02-23 20:11 ` Arnaldo Carvalho de Melo
2021-02-24 7:47 ` Evgenii Shatokhin
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).