4 ms·

So today musl discovered a longstanding bug in Linux's ELF loader

159 points by matthews2 4y ago

arjvik 4y ago
Could you explain why the kernel needs two copies of ELF loading code? I thought dynamically linked binaries are still ELF, but have special code to load shared object files into the right places in memory.
- p_l 4y ago
  Dynamically linked binaries aren't linked by kernel, but by "elf interpreter" specified by one of the elf header fields. This points to another binary which is executed in, iirc, slightly different way, with the intended binary file passed as well. The elf interpreter is then responsible for loading the file into memory, handling all the shared library linking or other special operations, and then jumps to actual programs start point as specified by elf header. Generally it does it by parsing the elf headers, resolving all the symbols recursively, and calling mmap() to properly allocate memory for the program as well as to mmap() the program text and libraries into memory. So there are two loaders involved even if kernel had only one, because the kernel loader is simplified and doesn't handle full scope of ELF nor is it supposed to handle dynamic linking.
  - deleted 4y ago
    [deleted]
mike_hock 4y ago
> I think Linux may also be failing to do the right zero-fill (leaving junk mapped from disk present) Is this heartbleed for ELF, or is the junk always mapped from the ELF binary itself (or the ldd binary, whose content is ostensibly common knowledge)?
- deleted 4y ago
  [deleted]
- toast0 4y ago
  Without looking at the code in question, I'd guess it's junk from the loader binary; mmaping the file into the range, but not filling the end properly seems like a much easier mistake than having a one off amd broken way to get disk content and a little extra into memory for loading loaders.
bregma 4y ago
Quick summary: it's possible to hand-craft a binary executable that won't run on Linux and the GNU ld.so does nothing to stop it.
- mort96 4y ago
  That's not what I read from this at all? My takeaway is that Linux has different ELF loading code for normal executables and for the dynamic linker (ld.so), the one for ld.so is buggy, and LLVM's linker (lld) produces binaries which trigger the bug, so an ld.so produced by lld won't work.
blinkingled 4y ago
Doesn't say if this was reported to the Linux kernel bugzilla - quick search doesn't turn up anything.
- dezgeg 4y ago
  Reporting bugs to the kernel bugzilla has high chance of being pointless. Most developers never use it. Needs to be posted to the mailing list (hardest part is locating the correct list).
  - stefantalpalaru 4y ago
  - matthews2 4y ago
    There's a good LWN article on the state of the kernel.org bugzilla: https://lwn.net/Articles/910740/ https://lwn.net/Articles/910740/
  - deleted 4y ago
    [deleted]
  - blinkingled 4y ago
    I remember it wasn't that bad before - not into kernel things anymore but I guess posting a slightly flashy bug report on the main LKML (linux-kernel@vger.kernel.org) should get some attention.
nraynaud 4y ago
I think those people doing alternative libc, compilers, etc. are also doing a great secondary job at dusting some very stable corners of Linux. And a third very big value is all those blog posts they generate to educate all of us lay people on some details of the system.
tristanbvk 4y ago
The rewrite in Rust comment just had to appear somewhere in that reply thread . Coming from a Rust enjoyer. Don't use it myself but see the benefits. But those oneliners always make me chuckle.
rurban 4y ago
So why didn't this bite us decades ago already? Multiple LOAD segments are quite common since GOT, very common. So there is random unzeroed junk at the end of BSS, which only bites us with release optimizations. Sounds security to me

159 points by matthews2 4y ago

Could you explain why the kernel needs two copies of ELF loading code? I thought dynamically linked binaries are still ELF, but have special code to load shared object files into the right places in memory.

p_l 4y ago
Dynamically linked binaries aren't linked by kernel, but by "elf interpreter" specified by one of the elf header fields. This points to another binary which is executed in, iirc, slightly different way, with the intended binary file passed as well. The elf interpreter is then responsible for loading the file into memory, handling all the shared library linking or other special operations, and then jumps to actual programs start point as specified by elf header. Generally it does it by parsing the elf headers, resolving all the symbols recursively, and calling mmap() to properly allocate memory for the program as well as to mmap() the program text and libraries into memory. So there are two loaders involved even if kernel had only one, because the kernel loader is simplified and doesn't handle full scope of ELF nor is it supposed to handle dynamic linking.
- deleted 4y ago
  [deleted]

mike_hock 4y ago

> I think Linux may also be failing to do the right zero-fill (leaving junk mapped from disk present) Is this heartbleed for ELF, or is the junk always mapped from the ELF binary itself (or the ldd binary, whose content is ostensibly common knowledge)?

deleted 4y ago
[deleted]
toast0 4y ago
Without looking at the code in question, I'd guess it's junk from the loader binary; mmaping the file into the range, but not filling the end properly seems like a much easier mistake than having a one off amd broken way to get disk content and a little extra into memory for loading loaders.

bregma 4y ago

Quick summary: it's possible to hand-craft a binary executable that won't run on Linux and the GNU ld.so does nothing to stop it.

mort96 4y ago
That's not what I read from this at all? My takeaway is that Linux has different ELF loading code for normal executables and for the dynamic linker (ld.so), the one for ld.so is buggy, and LLVM's linker (lld) produces binaries which trigger the bug, so an ld.so produced by lld won't work.

blinkingled 4y ago

Doesn't say if this was reported to the Linux kernel bugzilla - quick search doesn't turn up anything.

dezgeg 4y ago
Reporting bugs to the kernel bugzilla has high chance of being pointless. Most developers never use it. Needs to be posted to the mailing list (hardest part is locating the correct list).
- stefantalpalaru 4y ago
- matthews2 4y ago
  There's a good LWN article on the state of the kernel.org bugzilla: https://lwn.net/Articles/910740/ https://lwn.net/Articles/910740/
- deleted 4y ago
  [deleted]
- blinkingled 4y ago
  I remember it wasn't that bad before - not into kernel things anymore but I guess posting a slightly flashy bug report on the main LKML (linux-kernel@vger.kernel.org) should get some attention.

nraynaud 4y ago

I think those people doing alternative libc, compilers, etc. are also doing a great secondary job at dusting some very stable corners of Linux. And a third very big value is all those blog posts they generate to educate all of us lay people on some details of the system.

tristanbvk 4y ago

The rewrite in Rust comment just had to appear somewhere in that reply thread . Coming from a Rust enjoyer. Don't use it myself but see the benefits. But those oneliners always make me chuckle.

rurban 4y ago

So why didn't this bite us decades ago already? Multiple LOAD segments are quite common since GOT, very common. So there is random unzeroed junk at the end of BSS, which only bites us with release optimizations. Sounds security to me