One of my favourite explorations of the ELF format is linked in the comments. Just how small can you make an ELF executable? [0]. Spoiler: 45 bytes, when you go far enough that standard assemblers start getting in the way. When the ELF header becomes part of the program itself.
> Of course, half of the values in this file violate some part of the ELF standard, and it's a wonder that Linux will even consent to sneeze on it, much less give it a process ID. This is not the sort of program to which one would normally be willing to confess authorship.
> On the other hand, every single byte in this executable file can be accounted for and justified. How many executables have you created lately that you can say that about?
Wow, this was a dense, but enlightening, article. One question, though:
> To build this vector, the handler code first needs to push onto the stack any information that doesn't fit within a 64-bit value; for x86_64 this is a platform capability description (the string "x86_64") and 16 bytes of random data (to help seed user-space random number generators).
Why can't the string "x86-64" be fit in a 64-bit value? It's six characters, so shouldn't it be 48 bytes?
> Why can't the string "x86-64" be fit in a 64-bit value? It's six characters, so shouldn't it be 48 bytes?
48-bits, you mean, right? That's also missing the null terminator, which I assume is at the end of the string, but that still wouldn't put it at above 64 bits assuming that each character is a byte
So regardless of what architecture you're on and how long its platform capability description is, it goes on the stack. This also allows for for future expansion without forever constraining the string to be 64 bits.
One of my favourite explorations of the ELF format is linked in the comments. Just how small can you make an ELF executable? [0]. Spoiler: 45 bytes, when you go far enough that standard assemblers start getting in the way. When the ELF header becomes part of the program itself.
> Of course, half of the values in this file violate some part of the ELF standard, and it's a wonder that Linux will even consent to sneeze on it, much less give it a process ID. This is not the sort of program to which one would normally be willing to confess authorship.
> On the other hand, every single byte in this executable file can be accounted for and justified. How many executables have you created lately that you can say that about?
[0] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...
Wow, this was a dense, but enlightening, article. One question, though:
> To build this vector, the handler code first needs to push onto the stack any information that doesn't fit within a 64-bit value; for x86_64 this is a platform capability description (the string "x86_64") and 16 bytes of random data (to help seed user-space random number generators).
Why can't the string "x86-64" be fit in a 64-bit value? It's six characters, so shouldn't it be 48 bytes?
The string is a variable length field, and there are other platforms than x86_64 that use the same mechanism but have longer strings. E.g., https://elixir.bootlin.com/linux/v3.18/source/arch/arm64/inc... or https://elixir.bootlin.com/linux/v3.18/source/arch/parisc/ke... .
> Why can't the string "x86-64" be fit in a 64-bit value? It's six characters, so shouldn't it be 48 bytes?
48-bits, you mean, right? That's also missing the null terminator, which I assume is at the end of the string, but that still wouldn't put it at above 64 bits assuming that each character is a byte
> 48-bits, you mean
Gah, yes. The stupid thing starts with "b" as well. And yes, with the null terminator, it should come to 56 bits.
The code is architecture-independent. The article handily links to it: https://elixir.bootlin.com/linux/v3.18/source/fs/binfmt_elf....
So regardless of what architecture you're on and how long its platform capability description is, it goes on the stack. This also allows for for future expansion without forever constraining the string to be 64 bits.
Not about ELF at all, but related to this comment there:
https://lwn.net/Articles/632371/
acuozzo presented on HN the (re)discovery of Mel's picture in 2011:
https://news.ycombinator.com/item?id=3110906