linux-kernel - Re: [PATCH] trace/uprobes: fix output issue with address randomization

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:   Mon, 18 Dec 2017 12:59:40 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Thomas Richter <tmricht@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, mingo@...hat.com,
        heiko.carstens@...ibm.com, schwidefsky@...ibm.com,
        brueckner@...ux.vnet.ibm.com,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Tobin C. Harding" <me@...in.cc>
Subject: Re: [PATCH] trace/uprobes: fix output issue with address
 randomization

On Mon, 18 Dec 2017 16:32:25 +0100
Thomas Richter <tmricht@...ux.vnet.ibm.com> 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:

Hmm, since the scrambling of %p is to prevent kernel addresses from
leaking, I wonder if it would be OK to make it only scramble the address
if the address is a kernel address. It should be fine to print user
space addresses unscrambled. Shouldn't it?

-- Steve

> 
>  # 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@...olv/inet_pton.c
> 					in /usr/lib64/libc-2.26.so)
> 
> Signed-off-by: Thomas Richter <tmricht@...ux.vnet.ibm.com>
> Suggested-by: Peter Zijlstra <peterz@...radead.org>
> ---
>  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:
> -- 
> 2.13.4