Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760575AbdLSAZ7 (ORCPT ); Mon, 18 Dec 2017 19:25:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:50218 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759583AbdLSAZ6 (ORCPT ); Mon, 18 Dec 2017 19:25:58 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 72FF5218B4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=mhiramat@kernel.org Date: Tue, 19 Dec 2017 09:25:53 +0900 From: Masami Hiramatsu To: Peter Zijlstra Cc: Thomas Richter , Steven Rostedt , mhiramat@kernel.org, linux-kernel@vger.kernel.org, heiko.carstens@de.ibm.com, schwidefsky@de.ibm.com, brueckner@linux.vnet.ibm.com Subject: Re: [PATCH] trace/uprobes: fix output issue with address randomization Message-Id: <20171219092553.0ab0f7585f20234d2e0fbe64@kernel.org> In-Reply-To: <20171215173156.nvggmxozugo5jld5@hirez.programming.kicks-ass.net> References: <20171215153625.7657-1-tmricht@linux.vnet.ibm.com> <20171215173156.nvggmxozugo5jld5@hirez.programming.kicks-ass.net> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2944 Lines: 78 On Fri, 15 Dec 2017 18:31:56 +0100 Peter Zijlstra wrote: > > I'm not in fact the maintainer covering this file.. > > On Fri, Dec 15, 2017 at 04:36:25PM +0100, Thomas Richter wrote: > > Commit ad67b74d2469 ("printk: hash addresses printed with %p") > > changed %p to hash pointers in order to avoid leaking > > kernel addresses. > > > > This breaks the tool perf probe. > > > > To set a uprobe on a function named inet_pton in libc library, > > obtain the address of the symbol inet_pton using command nm and > > then use the following command to set the uprobe: > > > > # echo "p:probe_libc/inet_pton /usr/lib64/libc-2.26.so:0x142060" > > > /sys/kernel/debug/tracing/uprobe_events > > > > However the output shows a randomized address: > > # cat /sys/kernel/debug/tracing/uprobe_events > > p:probe_libc/inet_pton /usr/lib64/libc-2.26.so:0x000000002d0f8952 > > > > The displayed address 0x000000002d0f8952 is incorrect and breaks > > tools post processing it: > > > > # linux/tools/perf/perf probe -l > > Failed to find debug information for address 2d0f8952 > > probe_libc:inet_pton (on 0x2d0f8952 in /usr/lib64/libc-2.26.so) > > > > Using the %px printk format string fixes this issue for root > > and shows the correct address allowing the perf probe tool > > to resolve the address to the symbol: > > > > # echo "p:probe_libc/inet_pton /usr/lib64/libc-2.26.so:0x142060" > > > /sys/kernel/debug/tracing/uprobe_events > > # cat /sys/kernel/debug/tracing/uprobe_events > > p:probe_libc/inet_pton /usr/lib64/libc-2.26.so:0x0000000000142060 > > # linux/tools/perf/perf probe -l > > probe_libc:inet_pton (on __inet_pton@resolv/inet_pton.c > > in /usr/lib64/libc-2.26.so) > > > > Signed-off-by: Thomas Richter > > Suggested-by: Peter Zijlstra > > --- > > kernel/trace/trace_uprobe.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c > > index 40592e7b3568..268029ae1be6 100644 > > --- a/kernel/trace/trace_uprobe.c > > +++ b/kernel/trace/trace_uprobe.c > > @@ -608,7 +608,7 @@ static int probes_seq_show(struct seq_file *m, void *v) > > > > /* Don't print "0x (null)" when offset is 0 */ > > if (tu->offset) { > > - seq_printf(m, "0x%p", (void *)tu->offset); > > + seq_printf(m, "0x%px", (void *)tu->offset); > > } else { > > switch (sizeof(void *)) { > > case 4: > > So I had a wee peek and afaict this ends up at: > > trace_create_file("uprobe_events", 0644, d_tracer, > NULL, &uprobe_events_ops); > > which is a world readable file. Doesn't that leak the kaslr offset? As I correctly understand, this fix shows the correct offset in the file of the probe point, this means we fixes that leakage of the aslr offset, doesn't it? Thank you, -- Masami Hiramatsu