Date: Thu, 04 Mar 2021 19:18:11 -0800 From: Michael Forney <mforney@...rney.org> To: musl@...ts.openwall.com Subject: ld-musl-* and empty .eh_frame Hi, Érico noticed that cproc (my C compiler) produced executables that musl's dynamic linker fails to load when passed as an argument: /lib/ld-musl-x86_64.so.1: ./t: Not a valid dynamic program However, running ./t directly works fine. It turns out that this is because the executables have an empty .eh_frame section, which causes musl to attempt an mmap with length 0 which fails with EINVAL. GNU ld seems to always create a .eh_frame section in the final executable (unless you pass --no-ld-generated-unwind-info), regardless of whether any of the objects had one. Since none of the objects I built have an .eh_frame and none of musl's crt*.o have one, it ends up empty. gcc does not have this problem because its crtend.o has a non-empty .eh_frame (size is 4, so looks to be a CIE terminator according to LSB). Here's a short shell session demonstrating the problem: $ cat t.s .text .globl main main: movl $123, %eax ret $ as -o t.o t.s $ ld --dynamic-linker /lib/ld-musl-x86_64.so.1 -o t /lib/crt1.o /lib/crti.o t.o /lib/libc.so /lib/crtn.o $ ./t ; echo $? 123 $ /lib/ld-musl-x86_64.so.1 ./t /lib/ld-musl-x86_64.so.1: ./t: Not a valid dynamic program $ strace /lib/ld-musl-x86_64.so.1 ./t execve("/lib/ld-musl-x86_64.so.1", ["/lib/ld-musl-x86_64.so.1", "./t"], 0x7ffd8c17e4e8 /* 34 vars */) = 0 arch_prctl(ARCH_SET_FS, 0x7f3691752aa8) = 0 set_tid_address(0x7f3691754fd8) = 31726 open("./t", O_RDONLY|O_LARGEFILE) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0 \20@\0\0\0\0\0"..., 960) = 960 mmap(0x400000, 16384, PROT_READ, MAP_PRIVATE, 3, 0) = 0x400000 mmap(0x401000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x401000 mmap(0x402000, 0, PROT_READ, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = -1 EINVAL (Invalid argument) munmap(0x400000, 16384) = 0 writev(2, ["/lib/ld-musl-x86_64.so.1: ./t: N"...59, NULL0], 2/lib/ld-musl-x86_64.so.1: ./t: Not a valid dynamic program ) = 59 exit_group(1) = ? +++ exited with 1 +++ $ This leaves me with a few questions: 1. Is it invalid for an ELF executable to have an empty .eh_frame section? The only documentation I could find about it is , which says that it must contain one or more CFI records, so 0 would be invalid. 2. Is it the compiler's responsibility to link with an object containing a CIE terminator (like gcc's crtend.o) to prevent an empty .eh_frame section? 3. Is it a bug that GNU ld creates an empty .eh_frame by default, even when none of the objects it is linking have one? It looks like lld does not create an .eh_frame in this case. 4. Should musl's ld.so be able to handle such executables? The kernel does not seem to have a problem with it, as well glibc's ld.so with an executable I crafted with a 0-length .eh_frame section. Or perhaps some combination of the four? Any insight is appreciated. Thanks!  https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframechpt.html
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.