3 ms·

in consumer OSes, the 5% (or lower) performance hit of a microkernel is a big deal This does not feel like it should have been true for a long time. Computers

in consumer OSes, the 5% (or lower) performance hit of a microkernel is a big deal This does not feel like it should have been true for a long time. Computers are just stupidly fast now. In the 90s, sure, performance was way more important to prioritize, but I would love to see the needle swing the other way to getting a more secure and robust OS. My system already squanders so many resources on Electron JavaScript nonsense. Why not let the OS take up a few more cycles to give me hard security guarantees.

PaulHoule 2y ago
Somebody tell that to my iPad which goes out to lunch for 30 seconds when I am browsing the web and always seems to be listening to the music in its head. Or the XBOX that takes 30 seconds to sorta kind boot but really 3 minutes for all the menus to load.
mike_hearn 2y ago
You can do that and people already do. The most microkernelly consumer OS is macOS/iOS and there you see a lot of code has been moved out of the kernel with time. Example: whilst APFS is in-kernel by default that isn't much security risk. More vulnerable components like FAT drivers have moved into user space. On iOS the networking stack also runs in user space for apps that use Apple's APIs! https://devstreaming-cdn.apple.com/videos/wwdc/2017/707h2gkb95cx1l/707/707_advances_in_networking_part_1.pdf https://devstreaming-cdn.apple.com/videos/wwdc/2017/707h2gkb... So the whole TCP/IP stack is just a regular userspace library on that platform. Only the wifi driver runs in-kernel. These platforms are made up of literally hundreds of Mach servers. Relatively little code runs in the kernel when you examine the structure of the whole OS. The kernel is really only running some hardware drivers where moving them to userspace is hard, and some basics like memory management, process scheduling, IPC and code signature verification. The kernel just isn't that big. It's important to realize though that moving even more stuff to processes does not automatically improve security or availability. Imagine there's an RCE vuln in your root filesystem code. Being in a userspace server doesn't help you: 1. If you can control the FS you can make a root owned file appear anywhere and then just run it, or alter system configuration in any other way. 2. If you can crash the FS the core kernel can't easily recover without special cases because where would it restart the FS process from? If you say "initramfs" then you're back to having an FS in the kernel. In practice there are lots of cases like that. Sometimes it's worth it - modern OS' can generally recover from a display server crash and run graphics mostly in user space. Sometimes it's not. Finally, bear in mind that Linux is very insecure due to its huge feature set and reliance on C, but kernel exploits are often not the biggest security problem on other platforms. The most serious bugs are all in userspace already on most platforms.

PaulHoule 2y ago

Somebody tell that to my iPad which goes out to lunch for 30 seconds when I am browsing the web and always seems to be listening to the music in its head. Or the XBOX that takes 30 seconds to sorta kind boot but really 3 minutes for all the menus to load.

mike_hearn 2y ago

You can do that and people already do. The most microkernelly consumer OS is macOS/iOS and there you see a lot of code has been moved out of the kernel with time. Example: whilst APFS is in-kernel by default that isn't much security risk. More vulnerable components like FAT drivers have moved into user space. On iOS the networking stack also runs in user space for apps that use Apple's APIs! https://devstreaming-cdn.apple.com/videos/wwdc/2017/707h2gkb95cx1l/707/707_advances_in_networking_part_1.pdf https://devstreaming-cdn.apple.com/videos/wwdc/2017/707h2gkb... So the whole TCP/IP stack is just a regular userspace library on that platform. Only the wifi driver runs in-kernel. These platforms are made up of literally hundreds of Mach servers. Relatively little code runs in the kernel when you examine the structure of the whole OS. The kernel is really only running some hardware drivers where moving them to userspace is hard, and some basics like memory management, process scheduling, IPC and code signature verification. The kernel just isn't that big. It's important to realize though that moving even more stuff to processes does not automatically improve security or availability. Imagine there's an RCE vuln in your root filesystem code. Being in a userspace server doesn't help you: 1. If you can control the FS you can make a root owned file appear anywhere and then just run it, or alter system configuration in any other way. 2. If you can crash the FS the core kernel can't easily recover without special cases because where would it restart the FS process from? If you say "initramfs" then you're back to having an FS in the kernel. In practice there are lots of cases like that. Sometimes it's worth it - modern OS' can generally recover from a display server crash and run graphics mostly in user space. Sometimes it's not. Finally, bear in mind that Linux is very insecure due to its huge feature set and reliance on C, but kernel exploits are often not the biggest security problem on other platforms. The most serious bugs are all in userspace already on most platforms.