ELF Crimes: Program Interpreter Fun | Hacker News Reader

ELF Crimes: Program Interpreter Fun

nytpu.com

67 pointsnytpu14 comments

> But after getting the linked script setup working, even though it seemed like it should've been enough, it absolutely refused to work. It would only give me an opaque exec format error error, no matter how many different shotgun debugging things I tried, I ended up spending something like six hours over the course of two days on it with no real progress.

I think I would have eventually just loaded up a debugger and binary searched the codebase until I found the spot returning the error.

Because attaching a debugger to the Linux Kernel is so convenient and easy :P

But yeah, I was just being lazy and dumb. I solved it within ten minutes of someone saying "why don't you just go through the binfmt_elf code?" A debugger would've probably been more tedious than reading the relevant code directly, but would've been just as effective.

It's not and actually I do find it kind of amusing that Linux is possibly the hardest of the three main OSes to get a debugging set up for, but yeah I've had to do it enough that I don't mind doing and I can probably get it set up in a few minutes. Plus if the bug isn't in some architecture specific or hardware dependent thing there's this Linux compatibility userspace layer I help out on sometimes that is much easier to work with. And if it's that easy, I will generally choose to that instead of having to actually think about what I am doing ;)

I think you can do it with qemu and gdb.

Unless the other os and debugger mentioned has an easy way to do it with a machine that's not virtualized?

So I'm no kernel dev and only did a web search out of curiosity... Based on https://www.kernel.org/doc/html/latest/process/debugging/gdb... and https://sergioprado.blog/debugging-the-linux-kernel-with-gdb... , it reads as if it's fairly easy so long as you're willing to compile the kernel yourself. Actually, at that point I would personally favor UML, since at that point Linux is just a normal userspace program that you can attach to: https://www.kernel.org/doc/html/latest/virt/uml/user_mode_li...

But I'm not a kernel dev and it's been a very long time since I would have needed to debug the kernel; does this not actually work?

It’s a terrible shame Linux is still a 1970s program.

Plan 9’s debugger Acid can attach to a running kernel on a remote machine and debug it.

> It’s a terrible shame Linux is still a 1970s program.

This is a needlessly snide and inaccurate characterization.

> Plan 9’s debugger Acid can attach to a running kernel on a remote machine and debug it.

KGDB over Ethernet does the same on Linux.

Emulating a serial terminal emulating a teletypewriter emulating a punch card system.

If it works what do I care?

Because making it work is burdensome and writing programs that interact with it even more so.

I'm guessing you've never tried to write a terminal rendering program.

The hoops you hav to jump through to get vi to switch into a blank screen and then drop back and re-render your previous terminal.

Behaviour differences on some terminals when you run man and the previous output is simply cleared or the man page is printed and scrolled.

There are piles of hacks.

Ok, but what does this have to do with kernel debugging?

I know right, the price of cheese is quite volatile

"It just radiates jank" ... that line resonates with me, but is sonehow a bit attractive. Like this is how things might be done in some alternative grittier universe. Like this is how Kaylee would make data formats execute on the Firefly. Its steampunk programming.

OP would probably have a field day with NixOS's patchelf tool:

https://github.com/NixOS/patchelf

Reply on news.ycombinator.com