This writeup talks like MMU's always kill performance. It ignores over a decade of work by microkernels to reduce that problem to single-digit percentages. L4 even fits in a L1 cache with plenty room to spare. QNX also has clever low-oveehead scheduler & message passing. LynxSecure leaves CPU 97% or so idle at 100,000 context switches a second.
And all this even assumes you have to do the switch. That's not necessary if you split your system between kernel and user threads that run side by side on different cores with message passing, memory, or CPU interrupts to do notification.
So, not only are VM's and Unikernels old, their advocates are ignoring improvements to the other side of CompSci for MMU systems. Interestingly, that was the side making self-healing, live-updating, and NSA-resisting systems all these years on COTS hardware. A little weird that such architectures get the least attention. ;)
Good design does help a lot, but communication still isn't free. Commercial microkernels are usually sold on low, predictable latency ("real time"), not on raw throughput.
Do you happen to have any relevant references on modern anti-exploit technology like ASLR (which creates tons of MMU entries to describe the fragmented address space) and microkernels (which tend to rely on fast context switching)? I can imagine a few partial solutions, but... And no, "switch to OCaml" doesn't solve the problem. ;-)
ASLR is a tactic that was likely to be bypassed. High security doesnt rely on that. Microkernels are just a foundation to build on: components and interactions must be done right.
Far as modern tech, Ill try to get you a few when Im back on my PC at home. I have tons of them actually so I need to look again to apply the mental filter. Two interesting ones for you to Google for now are SVA-OS by Criswell and Code Pointer Integrity. Certain aspects of those have minimal overhead with strong prevention.
Best solutions are CPU mods that give better protections with lower costs. Especially memory safety. Architecture is main problem. All this other stuff is how we BAND-AID it. ;)
Oh, no you didn't! You saying Green Hills ain't been shipping? Secure64? Infineon? Better security != not shipping. Although, if I read that as a confession, then it might make a bit more sense. :P
re security mitigations
Ok. Thirty plus minutes into collection shows, aside from no organization, that I need to narrow this down. Most of great stuff is CPU modifications or compiler transformations that make safety/security easy. The HW has relatively low overhead in varying degrees of features supported while the SW approaches have significant overhead but support monoliths like Unikernels (or say Dom0). There are VM-style papers in my collection with clever, low-overhead stuff but bound to be breached like other clever stuff was. Nizza Security Architecture & MILS kernels are still best of that breed.
So, need to know if you're interested in the HW mods and/or stronger SW safety tricks. Honestly, they're most likely to pay off. Worst case: throw extra HW at either to cover performance hit. Will get cheaper in volume. Plus, a few are simple enough to apply to your domain if they do custom CPU's for RedFox, etc.
Completely agree. It would be nice if we could get some much better architectures in more common hardware. This stuff just isn't top of mind on anything in the SOC world (raspberry pi).
I think I'd agree, performance probably isn't the most compelling argument for unikernels, but it seems to be the one that's getting the most attention. Even from the performance perspective, eliminating context switches doesn't even seem like the most interesting aspect. The more interesting thing, at least to me, seems to be that a number of virtual mechanisms are implemented in hardware now, which in theory could allow for orders of magnitude reductions in latency (energy consumption).
Unikernels (ie library operating systems) on microkernels make a lot of sense. Microkernels do not provide the tcp stacks and so on that applications need after all. Xen is a microkernel architecture, but yes the more modern ones are attractive.
Unikernels on microkernels are fine. Far as TCP/IP, most production and some FOSS microkernels have those with some that heal themselves after crashes. Matter of fact, all high-assurance TCP/IP stacks run in a partitioned config on microkernels. And Xen is a hypervisor derived from a microkernel. It's not representative of most microkernels at all.
100,000 context switches doing what exactly? 99% of the time you will be bound by what the syscall does not overhead. Overhead will always be higher when you have to switch multiple contexts such as with a microkernel.
And all this even assumes you have to do the switch. That's not necessary if you split your system between kernel and user threads that run side by side on different cores with message passing, memory, or CPU interrupts to do notification.
So, not only are VM's and Unikernels old, their advocates are ignoring improvements to the other side of CompSci for MMU systems. Interestingly, that was the side making self-healing, live-updating, and NSA-resisting systems all these years on COTS hardware. A little weird that such architectures get the least attention. ;)