I think what may be overlooked here is that the entire premise is that a microkernel architecture is more secure because it (may) not suffer from the same problems that a monolithic kernel does. This may be true. What it doesn't address is what flaws a microkernel architecture has that a monolithic kernel does not. The notion that 1 architecture is 100% superior seems...unlikely. To me, this means it is less a question of which is better (since we're not actually comparing apples to apples) and which is easier to get work done with (because this is afterall, the point. If we can't get work done with it, it doesn't matter how good it is, its terrible). From this perspective, you can pick your poison, get used to it, and go back to getting work done. If your goal is academic research,
In terms of practical, I not aware of a microkernel architecture that is in broad use through the industry*, which means that, in terms of security, its effectively untested. Until you get thousands of people poking at something, you won't get an accurate representation of the security of a thing. Take a look at the CVE reports (mitre.org) for various popular platforms. They're pretty similar in terms of bug counts per year for at least the last 6yrs. Open Source, Closed Source doesn't have a lot of impact. * Yes, I know that OS X (Mac OS) is based on Mach Microkernel, but its more of a hybrid between the 2 architectures, so any security analysis comparisons to either are somewhat complicated. History/Reference/Description that is 11yrs old now, and of course some of it has changed. https://events.ccc.de/congress/2007/Fahrplan/attachments/986_inside_the_mac_osx_kernel.pdf > On Sep 13, 2018, at 10:17 AM, Tyrell Jentink <tyr...@jentink.net> wrote: > > I'm a young'n; I don't remember 4.4BSD or Research UNIX... I also come to > Linux from an IT background, not a Computer Science background, and maybe I > lack a certain historical perspective as a consequence. > > I was recently reading an article that claimed Linux is insecure, because > of it's monolithic kernel codebase: > https://threatpost.com/researchers-blame-monolithic-linux-code-base-for-critical-vulnerabilities/136785/ > > > That lead me down a trail of research on Wikipedia, trying to figure out > what they meant by that... And I discovered a number of interesting things: > > First, Many are likening it to a modern incarnation of the > Tanenbaun-Torvalds debates of the early '90s, which are also fascinating > https://en.m.wikipedia.org/wiki/Tanenbaum–Torvalds_debate > > But also, UNIX itself is old hat: Research Unix was a 1960s and 70's > approach to operating mainframes... By the 80's, Bell Labs had grown bored, > and wanted to start playing with distributed systems on commodity PCs, and > they started a new project, Plan 9 From Bell Labs ( > https://en.m.wikipedia.org/wiki/Plan_9_from_Bell_Labs); They doubled down > on the "Everything is a file, Programs should be small, and APIs should be > text based" philosophies... And they created the 9P2000 file sharing > protocol to share all of these "All resources are files" resources with > other computers... They also ignored existing standards, and had no > patience for existing software... It's still around, in the form of a > forked project called 9FRONT, http://9front.org. Fair warning: If you think > *BSD people are rude, these guys are worse in that they are also big fans > of sarcasm and irony... Rumor has it that new users regularly leave the IRC > crying... > > 9P2000 is still around, too, as the V9FS on Linux and many Unix like > operating systems, and growing popular in VM communities, > https://en.m.wikipedia.org/wiki/9P_(protocol) > > Then Bell Labs grew bored again... And in the 90's, built Inferno ( > https://en.m.wikipedia.org/wiki/Inferno_(operating_system) ), a system > built from lessons learned on Plan 9 From Bell Labs, but featuring a VM not > unlike Java; In fact, it can recompile Java bytecode to run natively. > Inferno is still around, developed by a third party: > http://www.vitanuova.com/inferno/ > > Both Plan 9 From Bell Labs and Inferno featured Microkernel technologies... > And in the '90s, Computer Science nerds grew obsessed over microkernels, > and born was the L4 microkernel architecture ( > https://en.m.wikipedia.org/wiki/L4_microkernel_family); They never say so, > but one can see many design similarities between all of the microkernels > and the earlier Plan 9/Inferno experiments. > > Where many like to argue that "Linux isn't an OS without GNU," > microkernels are even less an OS than Linux... in that it doesn't even > directly manage user rights or block devices or network routing... All of > that gets built as servers running in userspace, and THIS is the security > the original article was citing: By getting all that complicated and > potentially buggy software out of the kernel, the kernel can then protect > from the faulty code, and UNIX like operating systems can be built on top. > > Another project, Genode (https://en.m.wikipedia.org/wiki/Genode), aims to > add all the services needed to build more of the supporting framework of an > OS, I think of L4+Genode as being analogous to Linux; And a third, SculptOS > (https://genode.org/download/sculpt), to make it all a usable desktop OS, > akin to GNU/Linux. > > SculptOS isn't a Unix system per se, and they are quick to say so in their > documentation, but they do use familiar tools as a convenient interface to > the system... Like Bash and VIM. > > SculptOS is actually pretty cool, in that they achieved "General Purpose > OS" status by paravirtualizing Linux itself on top of the L4 kernel... > Think of it as GNU/Linux/L4 (GNU on Linux on L4), or something... I'm still > learning, too. There is a slight performance hit, but at 4%, it is > significantly less than a fully virtualized operating system... I think it > would be cool to run Windows and Linux side-by-side, each with only > marginal performance costs, and each running as a user service... > > The guys over at ReactOS dismiss L4 as "Just a Hypervisor," but I think > they are missing the big picture... This is opening the door to running > entire operating systems as services next to each other... It's like > Docker, but with WHOLE OPERATING SYSTEMS! > > I'm pretty excited... It's like taking my computer from a timeline where > the world stopped evolving in the 1960s, to something... A bit more > adventurous. > > At least... It feels that way on paper... And so far, I'm living on paper, > LOL. > > Of course... This entire history lesson ignores Mach, which is the > Microkernel under Mac OS and GNU/Hurd, and that might be interesting, too, > if GNU/Hurd weren't developing inside a drum of molasses in the Arctic... > > Anyone else playing with any of these "next generation" operating systems? > > On Thu, Sep 13, 2018, 05:25 Richard Owlett <rowl...@cloud85.net> wrote: > >> On 09/12/2018 05:50 PM, Keith Lofstrom wrote: >>> On Tue, Sep 11, 2018 at 04:03:33PM -0500, Richard Owlett wrote: >>>> Where should I go looking? >>> >>> http://catb.org/~esr/faqs/smart-questions.html >>> >> >> Haven't been referred there in quite awhile ;/ >> >> A more prosaic subject line might have been: >> "When/Why use a wiki? An alternative?" >> >> Perhaps deleting two sentences from the body would have reduced noise. >> >> It could have read: >> "My underlying problem is OS independent. However, I seek a Linux >> oriented solution. My language of choice does have a wiki. HOWEVER, >> anyone can modify anything at any time without immediate checks/balances." >> >> For detailed questions I participate in ~40 mailing lists and USENET >> groups. I've yet to find any web based fora which I can navigate. >> >> I mention wikis as I look for background. Wikipedia is well written but >> to broadly aimed. Arch wiki is well written and easily navigated but is >> narrowly focused. >> >> Overall, I still like my original subject line, >> "To wiki or not to wiki. THAT is the question." >> over the more prosaic >> "When/Why use a wiki? An alternative?" >> >> Thank you. >> >> >> >> >> _______________________________________________ >> PLUG mailing list >> PLUG@pdxlinux.org >> http://lists.pdxlinux.org/mailman/listinfo/plug >> > _______________________________________________ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug -- Louis Kowolowski lou...@cryptomonkeys.org Cryptomonkeys: http://www.cryptomonkeys.com/ Making life more interesting for people since 1977 _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
