.note.rustc dylib section flagged SHF_ALLOC on Linux (can cause crashes)

[tylerwhall]

Having the metadata note section flagged "alloc" can cause two types of crashes in certain environments.

1. Dynamic loader crash

Glibc's dynamic loader will try to allocate and copy the entire section onto the stack which will crash if the stack size is limited. This section is particularly large (~2MB for libstd) - not something that can generally be expected to fit on the stack.

The loader is searching for .note.ABI-tag, but does so by reading in any PT_NOTE headers. Because the metadata section is flagged alloc, it gets an entry in the program header, causing it to get loaded by this code.
http://osxr.org/glibc/source/elf/dl-load.c?!v=glibc-2.19#1869 (Note the alloca() at 1879)

I think this may be the cause of #22528, or other crashes with open_verify() in the call stack.

A workaround of using objcopy -R to remove the section fixes this problem, but leaves the object in a brittle state, described below.

2. Crashes in stripped and prelinked shared objects

Working around 1. by stripping out .note.rustc causes a problem with section numbering. Pulling the section out from before another ALLOC section (.bss in the example below) causes that section to be renumbered. Neither GNU strip nor objcopy fix the rest of the references in the executable that point to the section by its index. In particular, entries in the .dynamic section now point to the next section (.comment, here) which breaks when prelinking.

Prelink decides not to fix up the symbols in the dynamic section because it thinks they point to .comment, a section that didn't get relocated during prelinking. So BSS gets relocated, but the dynamic symbols point to the non-prelinked address, causing the program to segfault when it tries to access exported symbols in BSS.

readelf -S libstd-4e7c5e5c.so (current behavior)

  [25] .data             PROGBITS        001938a0 18b8a0 0001a0 00  WA  0   0 16
  [26] .note.rustc       NOTE            00193a40 18ba40 2088d2 00  WA  0   0 16
  [27] .bss              NOBITS          0039c320 394312 000dc8 00  WA  0   0 16
  [28] .comment          PROGBITS        00000000 394312 000011 01  MS  0   0  1
  [29] .ARM.attributes   ARM_ATTRIBUTES  00000000 394323 00003d 00      0   0  1
  [30] .debug_aranges    PROGBITS        00000000 394360 0011a0 00      0   0  8

To fix this, I'm currently using this patch as a workaround.
tylerwhall@fc91059
It runs objcopy on the intermediate metadata object to remove the alloc and write flags. This causes the final link to place the metadata section at the end of the executable and not generate a program header entry.

The fixed version has the metadata with no flags set, no load address, and located near the end of the file along with the debug sections where it can be safely stripped.

readelf -S libstd-4e7c5e5c.so (desired behavior)

  [25] .data             PROGBITS        001938a0 18b8a0 0001a0 00  WA  0   0 16
  [26] .bss              NOBITS          00193a40 18ba40 000dc8 00  WA  0   0 16
  [27] .comment          PROGBITS        00000000 18ba40 000011 01  MS  0   0  1
  [28] .ARM.attributes   ARM_ATTRIBUTES  00000000 18ba51 00003d 00      0   0  1
  [29] .note.rustc       PROGBITS        00000000 18ba90 2088a7 00      0   0 16
  [30] .debug_aranges    PROGBITS        00000000 394338 0011a0 00      0   0  8

Obviously running objcopy like this is not portable. Calling llvm::LLVMSetGlobalConstant() on the metadata variable is enough to remove the SHF_WRITE flag, but I couldn't find a way with LLVM's API to output a section that didn't request to be loaded at run time. Hopefully someone who knows more about LLVM can come up with a more elegant solution to remove SHF_ALLOC from the intermediate metadata object.

[eefriedman]

You could use module-level inline asm; not sure if that qualifies as "elegant".

[benpye]

Just to add, this is currently affecting WSL too, after applying the patch given (updated for current master), rust seems to run fine there. I equally can't find any way of specifying not to apply the SHF_ALLOC flag to the section with the LLVM API...

[eddyb]

To expand on that: LLVM internally removes SHF_ALLOC if SectionKind::getMetadata() is used but nothing "user"-facing touches it, only debuginfo and miscellaneous hardcoded sections 😞.

[eddyb]

My testcase so far:

#![crate_type="dylib"]
// Any large (>8MB AFAICT) file works, librustc_llvm happens to take up 44MB.
pub const BLOB: &'static [u8] =
include_bytes!("build/x86_64-unknown-linux-gnu/stage0/lib/librustc_llvm-a4922355.so");

Running ldd on the result gives me ldd: exited with unknown exit code (139).

[cuviper]

FYI, I filed a glibc bug about the improper alloca:
https://sourceware.org/bugzilla/show_bug.cgi?id=20419