> The Mac OS is pretty, well-designed components for GUI/desktop on top of a hybrid between a microkernel and UNIX (BSD). Let's ignore their bad choice of microkernel.
Is it necessary to ignore the microkernel choice? Isn't MacOS X -not- microkernel, even though (or "because") it uses an old version of Mach? [0][1][2]
Mach was a terrible microkernel because it tried to do too much. Good examples for you to look up are QNX, L4 (esp OKL4), EROS, and Minix 3. These all get stuff done more reliably, securely, and faster than Mach. That they've built so much into the Mach model means anything you do to improve security or performance has to fight with its inherent weaknesses.
So, Mach is its own discussion of failure in and of itself. There was also a history... Trusted Mach, Distributed TMach, DTOS... of trying and failing to secure Mach using high-assurance methods. The security improvements in new Mac OS's, esp sandboxing and such, were actually recommended with that old research in mind. They realized the foundation wasn't going to be secured as it never worked in the past. So, they went for decomposition and isolation schemes for apps themselves plus IIRC integration of TrustedBSD mechanisms.
I appreciate the links. I'm still perplexed though -- isn't the Mach component of MacOS X not at all a microkerel? Are you saying "it sort of is", or "it certainly is" ?
The promises of microkernels seem extremely attractive to me, but we know that the promise of simplicity doesn't come for free (witness Hurd[0]). There were versions of Mach that were high-profile (i.e.: media/developer attention) microkernels, but I thought the Mach in MacOS X really
was simply "not a microkernel". Interested to hear more about this if you've got illuminating info.
XNU is monolothic software since it (a) merges code like BSD in with the microkernel and (b) has a ton of kernel-mode code in violation of microkernel principles. It can be said that microkernels can still benefit monolithic heaps of kernel code by providing a consistent, simple way for pieces to internally communicate. Windows has a microkernel inside of it for that reason IIRC.
"witness Hurd[0]"
Hurd is another failure. So many microkernels, including commercial deployments, have happened during the lifetime of that project not achieving its goals. Situations like Mach and Hurd are why people think microkernels suck. You have to see good examples. Did you ever use a Windows 95/98 box back in the day? Remember how it would choke trying to do anything intensive or concurrent? Check out what microkernel-based BeOS does on older hardware in my UNIX alternatives list:
Tannenbaum has a nice paper describing the two biggest problems plus different styles of handling them. It includes the microkernel techniques that are reason we like them for robustness.
On capability-security site, KeyKOS had fine-grained isolation, protected communication, and checkpointing of app's state in case of failures. Shapiro's successor, EROS, is described in this document along with many key principles to high-assurance reliability and security that good work must leverage:
Note: Unfortunately, project is dead as FOSS contributors had little interest and he got poached by Microsoft. Did deliver a more secure networking stack and GUI system on top of a prototype kernel. COYOTOS project papers have some lessons learned, too.
So, Mach is its own discussion of failure in and of itself. There was also a history... Trusted Mach, Distributed TMach, DTOS... of trying and failing to secure Mach using high-assurance methods. The security improvements in new Mac OS's, esp sandboxing and such, were actually recommended with that old research in mind. They realized the foundation wasn't going to be secured as it never worked in the past. So, they went for decomposition and isolation schemes for apps themselves plus IIRC integration of TrustedBSD mechanisms.