[HN Gopher] So today musl discovered a longstanding bug in Linux...
___________________________________________________________________
So today musl discovered a longstanding bug in Linux's ELF loader
Author : matthews2
Score : 149 points
Date : 2022-11-05 08:54 UTC (14 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| mike_hock wrote:
| > 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]
| bregma wrote:
| 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 wrote:
| 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.
| tristanbvk wrote:
| 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.
| nraynaud wrote:
| 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.
| blinkingled wrote:
| Doesn't say if this was reported to the Linux kernel bugzilla -
| quick search doesn't turn up anything.
| dezgeg wrote:
| 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).
| matthews2 wrote:
| There's a good LWN article on the state of the kernel.org
| bugzilla: https://lwn.net/Articles/910740/
| [deleted]
| stefantalpalaru wrote:
| blinkingled wrote:
| 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.
| arjvik wrote:
| 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 wrote:
| 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]
___________________________________________________________________
(page generated 2022-11-05 23:02 UTC)