Re: 'perf probe' and symbols from .text.<something>

From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Evgenii Shatokhin <eshatokhin@virtuozzo.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Kristen Carlson Accardi <kristen@linux.intel.com>,
	live-patching@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org,
	Konstantin Khorenko <khorenko@virtuozzo.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)
In-Reply-To: <20210223163619.0cd580a4290165208c8aa7bb@kernel.org>

On Tue, Feb 23, 2021 at 04:36:19PM +0900, Masami Hiramatsu wrote:
> On Tue, 23 Feb 2021 10:23:31 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > On Mon, 22 Feb 2021 11:51:50 -0600
> > Josh Poimboeuf <jpoimboe@redhat.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.

-- 
Josh