One more bit of proof that if you want proper isolation you should not bloat your kernel. All this stuff belongs in userland. At least there the damage will be limited.
In a context that doesn't involve executing it. On a Linux system, this functionality would probably be implemented with libelf or libbfd, neither of which depends on the kernel.
Then again, the kernel already has such a gigantic attack surface that it doesn't matter if the ELF parser is part of it.
A model in which this happens in userspace is conceivable, but it'd be pretty weird. Besides, it introduces a chicken-and-egg problem -- if you need a process to launch a process, you need some sort of special case for init.
Of course the ELF parsing doesn't literally have to be done by the kernel, but there's no obvious good place to put it otherwise, considering it's a critical bit. If security is the real concern, then why wouldn't you just drop privileges while parsing ELF instead? I don't see the benefit to moving this code outside of the kernel. Maybe somehow moving it to a different protection ring would be helpful; but same for the rest of the binfmts.
I believe the Windows loader that loads PE files, is in fact in the kernel, along with a lot of other stuff. At the end of the day, when the Windows NT kernel was architected, speed was really important and security practices were not matured. I mean, the kernel handles or at once handled a lot of stuff, especially related to the GUI and even network RPCs and network services.
And goes for a lot of other kernel code.
Even for statically linked executables?
That is, the parse logic could be a library linked by multiple application.
Yes, please.
NT tends to be conceptually about the right trade-off (micro-kernel design, but no context switching) but then they go do stupid crap like this.
Others don't, for example tons of embedded devices.
If you have a small, fast kernel it could be used on a variety of devices, from Raspberry Pi to Mac Pro.
But it serves to discourage anything that isn't actual conversation, which might not be a bad plan in the end.
In rare instances pictures add to the conversation. But 99 times out of 100, that pic is some reaction gif (spongebob, wat, etc). And I'd argue that these reaction images are completely worthless.
In a way, it's also the comparison between fb or reddit vs HN or lobste.rs .
The difference is I can avoid most of that crap when I have to write performance sensitive code, I cannot avoid a slow system without dropping down to the hardware.
fs/binfmt_elf.c is over 2k lines.