From: Alexander Monakov <amonakov@ispras.ru>
To: fREW Schmidt <frioux@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Linux Kernel <linux-kernel@vger.kernel.org>,
musl@lists.openwall.com
Subject: Re: Broken vDSO on built kernel
Date: Thu, 9 Jun 2016 00:36:20 +0300 (MSK) [thread overview]
Message-ID: <alpine.LNX.2.20.1606090027450.14709@monopod.intra.ispras.ru> (raw)
In-Reply-To: <CADVrmKTb84=bMSS38e_ppbJdA6CjRQNNvLybaw+4ktZHd7jHQw@mail.gmail.com>
On Wed, 8 Jun 2016, fREW Schmidt wrote:
> I was debugging an issue I ran into (
> https://github.com/docker/docker/issues/23378) and after chatting with the
> folks in #musl and we triaged it down to a broken vDSO (tested by running
> `strace date` and seeing a clock_gettime call.)
To provide a bit more detail, we've found that the vdso mappend into the
application has no dynamic symbols; Glibc ignores the vdso, so it continues to
work, but musl segfaults since the vdso is invalid.
I'm pasting below `readelf -aW` output on the vdso dumped on the affected
system (via 'fwrite((void*)getauxval(AT_SYSINFO_EHDR), 8192, 1, stdout)';
as you can see, there's no dynamic symbols and symbol hash tables. It may
be a toolchain bug since there was no issue with 4.6 kernel (and reportedly
there were no significant vdso changes merged into 4.7 -- the issue is seen
on Ubuntu's 4.7rc2).
Alexander
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: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x600
Start of program headers: 64 (bytes into file)
Start of section headers: 2976 (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: 10
Section header string table index: 9
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .rodata PROGBITS 0000000000000120 000120 000340 00 WA 0 0 1
[ 2] .note NOTE 0000000000000460 000460 00003c 00 A 0 0 4
[ 3] .eh_frame_hdr PROGBITS 000000000000049c 00049c 00003c 00 A 0 0 4
[ 4] .eh_frame PROGBITS 00000000000004d8 0004d8 000120 00 A 0 0 8
[ 5] .text PROGBITS 0000000000000600 000600 0004c9 00 AX 0 0 16
[ 6] .altinstructions PROGBITS 0000000000000ac9 000ac9 000034 00 A 0 0 1
[ 7] .altinstr_replacement PROGBITS 0000000000000afd 000afd 00000c 00 AX 0 0 1
[ 8] .comment PROGBITS 0000000000000000 000b09 00002e 01 MS 0 0 1
[ 9] .shstrtab STRTAB 0000000000000000 000b37 000067 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x000b09 0x000b09 R E 0x1000
DYNAMIC 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 R 0x8
NOTE 0x000460 0x0000000000000460 0x0000000000000460 0x00003c 0x00003c R 0x4
GNU_EH_FRAME 0x00049c 0x000000000000049c 0x000000000000049c 0x00003c 0x00003c R 0x4
Section to Segment mapping:
Segment Sections...
00 .rodata .note .eh_frame_hdr .eh_frame .text .altinstructions .altinstr_replacement
01
02 .note
03 .eh_frame_hdr
There is no dynamic section in this file.
There are no relocations in this file.
The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported.
No version information found in this file.
Displaying notes found at file offset 0x00000460 with length 0x0000003c:
Owner Data size Description
Linux 0x00000004 Unknown note type: (0x00000000)
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 496e9db3f494533ffaaf39737eb1023938861349
next prev parent reply other threads:[~2016-06-08 21:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 21:18 fREW Schmidt
2016-06-08 21:36 ` Alexander Monakov [this message]
2016-06-09 17:40 ` [musl] " Andy Lutomirski
-- strict thread matches above, loose matches on Subject: below --
2016-06-08 21:13 fREW Schmidt
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.20.1606090027450.14709@monopod.intra.ispras.ru \
--to=amonakov@ispras.ru \
--cc=frioux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).