| 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
| ||
|
Message-ID: <20150626145835.GD9791@arm.com>
Date: Fri, 26 Jun 2015 15:58:36 +0100
From: Will Deacon <will.deacon@....com>
To: Adrian Hunter <adrian.hunter@...el.com>
Cc: "acme@...hat.com" <acme@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Kristina Martsenko <Kristina.Martsenko@....com>,
Vladimir Nikulichev <nvs@...icks.com>,
Namhyung Kim <namhyung@...nel.org>, luto@...capital.net
Subject: Re: [PATCH] perf tools: don't adjust symbols in vDSO
(CC'ing Andy, since the removal of VDSO_PRELINK is user-visible here)
Hi Adrian,
Thanks for your helpful responses.
On Fri, Jun 26, 2015 at 02:55:29PM +0100, Adrian Hunter wrote:
> On 26/06/15 15:23, Will Deacon wrote:
> > On Thu, Jun 25, 2015 at 02:32:13PM +0100, Adrian Hunter wrote:
> >> On 24/06/15 19:17, Will Deacon wrote:
> >>> Commit 922d0e4d9f04 ("perf tools: Adjust symbols in VDSO") changed the
> >>> ELF symbol parsing so that the vDSO is treated the same as ET_EXEC and
> >>> ET_REL binaries despite being an ET_DYN.
> >>>
> >>> This causes objdump, which expects relative addresses, not to produce
> >>> any output in conjunction with perf annotate, which cheerfully passes
> >>> absolute addresses when trying to disassemble vDSO functions.
> >>>
> >>> This patch avoids marking the vDSO as requiring adjustment of symbol
> >>> addresses, allowing the relative program counter to be used instead.
> >>>
> >>> Cc: Vladimir Nikulichev <nvs@...icks.com>
> >>> Cc: Adrian Hunter <adrian.hunter@...el.com>
> >>> Cc: Namhyung Kim <namhyung@...nel.org>
> >>> Reported-by: Kristina Martsenko <kristina.martsenko@....com>
> >>> Signed-off-by: Will Deacon <will.deacon@....com>
> >>> ---
> >>>
> >>> Not sure why I've just started seeing this, but it appears to affect
> >>> both x86 and arm64. Also, if I revert the patch above then the issue
> >>> it supposedly fixed doesn't resurface. Maybe it was just masking another
> >>> bug that has since been addressed?
> >>
> >> No the problem still appears on older kernels.
> >
> > Can you be more specific, please? I tried with a 3.16 kernel (that I happen
>
> 3.13 Ubuntu kernel
So I just tried that on a core2 box and it's broken even without my patch:
# ./perf record -e cycles:u ./vdso-test
[...]
# ./perf report
[...]
# Overhead Command Shared Object Symbol
# ........ ......... ................. ........................
#
99.70% vdso-test [vdso] [.] __vdso_clock_gettime
[...]
# ./perf annotate -v
[...]
annotating [0x2178d10] [vdso] : [0x258bbd0] __vdso_clock_gettime
Executing: objdump --start-address=0x00007fff5eb9a870 --stop-address=0x00007fff5eb9ab4c -l -d --no-show-raw -S -C /home/nanook/.debug/.build-id/51/54a08e7153b1deecc09259d1e970f9b67e1664
[...]
Percent | Source code & Disassembly of [vdso] for cycles:u
----------------------------------------------------------------
870: 4
876: 2
87f: 2
920: 2
93a: 2
967: 2
985: 1
988: 3
9a2: 2
9bb: 1
9c8: 6
9d6: 2
9d9: 4
a9d: 4
ab4: 2
ab8: 13
ac0: 1
ac7: 3763
ac9: 5
h->sum: 3821
:
:
[...]
So there's no disassembly output for the vdso using a perf tool build
from a vanilla 4.1 kernel.
If I run readelf on the generated ELF object, I see:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0xffffffffff700700
Start of program headers: 64 (bytes into file)
Start of section headers: 3600 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 4
Size of section headers: 64 (bytes)
Number of section headers: 18
Section header string table index: 17
Text section:
[15] .text PROGBITS ffffffffff700700 00000700
000000000000062d 0000000000000000 AX 0 0 16
So somehow the Image claims to be loaded at 0xffffffffff700000,
whilst perf's map is offset by 0x00007fff5eb9a000. This seems to be down
to the #define VDSO_PRELINK 0xffffffffff700000 in older kernels, but your
patch doesn't take that fixed address into account, so I don't see how
it's ever the right thing to do.
At least with my patch applied, recent kernels work. Without it, vdso
disassembly appears to be broken on all kernels for all architectures.
> > to be running on my box) but perf doesn't even detect the vdso there,
> > regardless of this patch.
>
> Don't know what you mean about not detecting vdso
It just prints something like [perf.data.XXXX] instead of [vdso] -- probably
a separate bug.
Will
--
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/
Powered by blists - more mailing lists