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.
A UNIX-style process spawning interface, like exec() or posix_spawn(), requires the kernel to have some awareness of the executable format so that it can create a process from an executable image. It doesn't have to support every feature of the format, though.
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.
IIRC, the binfmt elf code in the Linux kernel basically only does enough elf parsing to map everything into memory and kick off the linker. Then the linker does the rest, in userland. It matters because the binfmt code can be very hardened and minimal, whereas the userspace can go and do whatever it wants.
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.
For a statically linked executable, the minimal parsing is enough to kick off the executable directly. After all, the linker is "just" a statically linked executable...
But here's a question - supposing that this functionality was moved into a hypothetical library "pe.dll"/"pe.exe", how would the kernel load this library or executable?
Wouldn't one run into a catch-22 situation?
I think they're saying that userland should handle whatever the mouseover is trying to do (another comment says it displays author and version info embedded in the exe). Things that actually require kernel privileges would remain in the kernel.
wouldn't you load/call it during boot or when the mouse driver loads? If you have a mouse, you are almost certainly going to generate an on-mouse-over event at some point. The advantage is that it isn't running in ring 0.
Its crazy that the arguments against microkernels were basically 100% its slower.. Which these days is completely batshit insane because we are running software in VM's eating 10%+ system performance, written in languages like Java/Javascript/etc which eat another 50% before the cowboy coder comes along and imports 2GB of libraries which effectively trash the caches/tlb/etc at every opportunity due to the difficulty of creating caches with massive associativity. Which is how we get chat apps written in electron eating up a couple 4+Ghz cores and multiple GB of memory just to display what was basically possible in with mIRC and 64k of ram 20 years ago.
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.
LOL, just post a link to the rich content, that is how its mostly done with hexchat these days. Of course you could just DCC the content to someone too.
But it serves to discourage anything that isn't actual conversation, which might not be a bad plan in the end.
Having been on chat from slack to discord to reddit chat to telegram... I focus back on IRC for its simplicity and lack of video and image-spam
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 .
> Its crazy that the arguments against microkernels were basically 100% its slower.. Which these days is completely batshit insane because we are running software in VM's eating 10%+ system performance, ...
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.
Slow is very relative here, the performance penalties are on the order of 5 to 10% or so in absolute throughput terms, latency is usually much better in a microkernel based system because it can use the cores more effectively and even quite a bit of the message passing overhead can be caught as long as you stay on the same physical machine by using the paging mechanism.
Linux uses libelf to parse the executable, it isn't in the kernel. It's a sort of weird process but binfmt will load libelf, which is then responsible for loading the ELF file.
Dissenting opinion: if this wasn't in the kernel it's unlikely to have been fixed as quickly --- explorer.exe crashes are unfortunately still common even without third party extensions. If they were causing BSODs they would certainly be given more attention and fixed more quickly.
Well, that would mean no more kernel bugs and that would reduce the impact of these issues substantially. If that would translate into the bug getting fixed that's a supplier issue, but no longer a major one.
When explorer (the shell and file browser, don't know if those are fully separate under Win 10) crashes, it is automatically restarted and would not close any other running programs and would not log you out.
...and that's probably the reason why they don't seem to get fixed. I've had clean installs of Win10 and 8.1 crash it often, just by browsing through a lot of files.
Thats a regular occurrence for me and people I know. My boss inserted a USB drive and Explorer crashed. It restarted itself, but crashed again. Until the drive was unplugged, at which time Windows made a bunch of error noises and popped up a "Catastrophic failure" dialog. It then worked OK after the USB drive was reinserted. The laptop cost ~3500€ and was installed and set up by the IT department with extra care because it's for the boss. It didn't matter, Windows 10 doesn't pick it's victims.
