4 ms·
As a thought experiment, let's make QNX faster. We keep the same IPC mechanism. We compile the filesystem process right into the kernel. Having done this, we c
by burfog 11y ago
As a thought experiment, let's make QNX faster.
We keep the same IPC mechanism. We compile the filesystem process right into the kernel. Having done this, we can now avoid half of the IPC mechanism. We enter the "microkernel" just once now, instead of twice, and we leave it once instead of twice. Since the filesystem is now in the "microkernel", we don't need to switch MMU state and have a TLB invalidate. This is a huge win. Now let's repeat this design change for the disk driver, the network stack, the network hardware driver, and all the rest. Performance keeps getting better. This, BTW, is pretty much what most Mach systems ended up doing. They became microkernel in marketing only. The final step is to clean up the code, and then you have a normal monolithic kernel.
Let's also look at things from the other perspective. You could add the QNX IPC mechanism into any monolithic kernel. AFAIK, Solaris DOORS might even qualify. Well, there you go. You can move things to use that whenever you are willing to sacrifice speed and maintainability. If this is so good, why haven't people done it? Hmmm.
- nickpsecurity 11y ago"Performance keeps getting better." Performance is great until those things crash my system. The stuff still happens with graphics drivers on my Linux distro's. I know it's not necessary because it doesn't happen on the microkernel systems and even Windows dodges a lot of it with their SLAM toolkit. "Let's also look at things from the other perspective. You could add the QNX IPC mechanism into any monolithic kernel. " Congratulations: you've just reinvented security kernels w/ legacy support from the 80's-90's plus modern separation kernels w/ legacy support of the 2000's. Here's an example to support your point that our model is better with microkernels, user-mode drivers, and monolithic API's in isolated partitions: https://www.usenix.org/legacy/events/sec04/tech/wips/wips/04-hohmuth-nizza.pdf https://www.usenix.org/legacy/events/sec04/tech/wips/wips/04... Even just putting the drivers and a few critical components in partitions can work wonders. That's what Nizza-like architectures like Turaya and Genode do. Their TCB's are many fold smaller than UNIX's with acceptable performance. You don't even notice it with the laptops of commercial ones (eg INTEGRITY-178B, LynxSecure, VxWorks MILS). Plus, there's around a billion mobile phones running OKL4 mainly for baseband or legacy isolation alongside Android or Windows Mobile. Notice how your smartphone is so much slower than older ones that didn't do that? Wait, you thought it was faster and better than the last one? Exactly. :)
- nwmcsween 11y agoIMO microkernels are a dead end, to get better performance you have to shove stuff in kernelspace, while for say an exokernel the opposite is mostly true.
- pjmlp 11y agoIf they are a dead end, why do they rule the embedded and real time OSes?
- nickpsecurity 11y agoIf we're talking tech, then your post couldn't be more wrong given my BeOS and QNX examples. Performance was equal to or better than monoliths of the time. BeOS especially destroyed competition in concurrency performance due to its architecture. QNX runs at hardware speed basically with real-time properties and POSIX support. BeOS disappeared due to Microsoft monopoly with Haiku making a OSS clone. QNX was at $40 million a year in revenue when Blackberry bought it. Green Hills and VxWorks are doing OK, too, with VxWorks making more than QNX per quarter. Both have desktops virtualizing Windows, Linux, etc on microkernels w/ Gbps throughput. I don't see why we keep getting these theoretical counters given the proven results of microkernel performance in the field. Tell me why microkernels are too slow when they can only do this on 90's era hardware: https://youtu.be/BsVydyC8ZGQ?t=16m9s https://youtu.be/BsVydyC8ZGQ?t=16m9s Then, tell us why we should sacrifice isolation of malice and faults in favor of kernel-mode code with properties like this: https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... Our side produced highly reliable and secure systems plus high-performance systems. It was always done with a small group with little time. The monoliths took a decade and thousands of man hours to do the same. It's up to you people to justify why those hours were well-spent. "while for say an exokernel the opposite is mostly true." An exokernel is a microkernel...
- burfog 11y agoI've seen the VxWorks code. VxWorks is not a microkernel. That BeOS demo did not heavily use privileged interactions. Mostly it showed computation which is the same on any OS. The best thing it showed was a process scheduler which was good at giving priority to things that a user would care about. A more interesting test would be serving files or building software. I think one should be careful not to read too much into CVE numbers. People aren't exactly trying to mess with KeyKOS, Haiku, QNX, and other weird things. Few people want to bother. None of the Linux problems are inherently specific to monolithic design. The best you could say is the you might have a sandbox that makes things more difficult for the attacker. On the other hand, restarting means you give attackers more chances to succeed.
- bogomipz 11y agoWhat exactly is the QNX IPC system? How is it different from regular IPC? Can mapping QNX into the top of userspace processes avoid the TLB flush/invalidate? I vaguely remember the Solaris Doors which is similar to pipe correct? How does it relate to this discussion. Thanks.