Slashdot Mirror
Linux Study Argues Monolithic OS Design Leads To Critical Exploits (osnews.com)
Long-time Slashdot reader Mike Bouma shares a paper (via OS News) making the case for "a small microkernel as the core of the trusted computing base, with OS services separated into mutually-protected components (servers) -- in contrast to 'monolithic' designs such as Linux, Windows or MacOS."
While intuitive, the benefits of the small trusted computing base have not been quantified to date. We address this by a study of critical Linux CVEs [PDF] where we examine whether they would be prevented or mitigated by a microkernel-based design. We find that almost all exploits are at least mitigated to less than critical severity, and 40% completely eliminated by an OS design based on a verified microkernel, such as seL4....
Our results provide very strong evidence that operating system structure has a strong effect on security. 96% of critical Linux exploits would not reach critical severity in a microkernel-based system, 57% would be reduced to low severity, the majority of which would be eliminated altogether if the system was based on a verified microkernel. Even without verification, a microkernel-based design alone would completely prevent 29% of exploits...
The conclusion is inevitable: From the security point of view, the monolithic OS design is flawed and a root cause of the majority of compromises. It is time for the world to move to an OS structure appropriate for 21st century security requirements.
Our results provide very strong evidence that operating system structure has a strong effect on security. 96% of critical Linux exploits would not reach critical severity in a microkernel-based system, 57% would be reduced to low severity, the majority of which would be eliminated altogether if the system was based on a verified microkernel. Even without verification, a microkernel-based design alone would completely prevent 29% of exploits...
The conclusion is inevitable: From the security point of view, the monolithic OS design is flawed and a root cause of the majority of compromises. It is time for the world to move to an OS structure appropriate for 21st century security requirements.
Maybe Tanenbaum was right. 26 years isn't that long for this debate to come back around again.
...si hoc legere nimium eruditionis habes...
Tanenbaum - Torvalds debate
The debate opened on January 29, 1992, when Tanenbaum first posted his criticism on the Linux kernel to comp.os.minix, noting how the monolithic design was detrimental to its abilities, in a post titled "LINUX is obsolete".[1] While he initially did not go into great technical detail to explain why he felt that the microkernel design was better, he did suggest that it was mostly related to portability, arguing that the Linux kernel was too closely tied to the x86 line of processors to be of any use in the future, as this architecture would be superseded by then. To put things into perspective, he mentioned how writing a monolithic kernel in 1991 is "a giant step back into the 1970s".
Since the criticism was posted in a public newsgroup, Torvalds was able to respond to it directly. He did so a day later, arguing that MINIX has inherent design flaws (naming the lack of multithreading as a specific example), while acknowledging that he finds the microkernel kernel design to be superior "from a theoretical and aesthetical" point of view.
Hurry, someone finish Hurd.
Consider QNX and its vulnerabilities (the entire software stack) and here's what we have for the Linux kernel (again, kernel alone) whose source is ostensibly verified by millions of eyes.
And here's another almost shameful development: Linux and Open Source are all the rage amongst Open Source fans, yet for some reasons it's been hinted that Google is transitioning from the monolithic Linux kernel (lacking internal stable API/ABI) to its own microkernel, Fuchsia (with stable API/ABI).
The NT microkernel design came from Digital (DEC) VMS operating system which was running VAX minicomputers. VAX/VMS was arguably the most secure OS at the time, and incredibly annoying to use due to that fact (everything required privileges, all the files were versioned, horrible shell syntax etc).
Yeah but still everyone's going the wrong way on the highway, keep being you!
After 28 years, you think someone would have finished the GNU Hurd kernel. By now, it is so old it is probably full of potential exploits, too.
... all it takes is time and effort. The idea that computers can be "secure" when they need to be fundamentally honest if one is to maintain performance of being demanded its a bit of bullshit. You can have slow and secure or you can have blazing fast and honest. Many "Security issues" are really just artifacts of hardware or software architecture.
The reality is security has to be designed from the get go from both a hardware and software standpoint, you can't just do it when fundamentally for most of x86's history it's been an open platform. Security can't be had on open platforms, in fact most issues would never have arisen pre-internet.
The reality is the speed at which computers operate and the demands for security are at odds, no one is willing to pay the true costs because it's just not worth the time and resources unless you are a big organization and have lots of money to throw around.
These days, the largest security threat is probably web browsers: They usually have direct access to the most critical information a user has (passwords, all personal files under their user account, data from all the external services the user accesses, etc.) Under the very same OS user account, web browsers also download and run thousands of untrusted programs from random locations on the internet every day (we'll ignore the handful of hardcore geeks who run Noscript).
The boundary separating these two realms is enormous and incredibly convoluted, involves many layers of abstraction (some of which can be breached by a single misplaced bracket or quote character), and is enforced entirely by the web browser itself. It presents a massive attack surface that dwarfs even the most monolithic OS API.
It's not quite accurate to say the "design came from Digital..." Dave Cutler, who worked on VMS V4 went to work for MS and built the W/NT (Windows/New Technology, and also WNT=VMS+1) based on the knowledge he'd acquired at Digital. Digital sued, and won.
The VAX/VMS system, later OpenVMS (because "Open" was a popular word, not because it was any more open than any other proprietary O/S, although you could get sources, originally on microfiche and later on CD) not only WAS but still IS one of the most secure systems. Banks, hospitals, medical facilities, and the government continue to use it today because of that.
You don't like the "horrible shell syntax"? No worries, Dave Kashtan from SRI/TGV/Cisco wrote Eunice, a Unix-style shell and tools so you could have your favorite CLI environment without having to learn Digital Comand Language (DCL). Dave and Ken Adelman (the guy who beat Barbra Streisand and created her eponymous "effect") used their knowledge of the VMS kernel and Eunice to write a TCP/IP networking stack that worked with the kernel at kernel speeds... beating out the inferior stacks by halfass developers like Process Software, Wollongong, and even Digital itself. (Of note is that Carnegie Mellon University built an open-source stack called CMU-TEK that (once Tektronix released their claims on it) was free, you could build it yourself, and was a great learning experience).
The point of all this is that the VMS kernel was secure, is secure, but wasn't a microkernel at all. While it made system calls to the File Management System (FMS) and the On Disk System (ODS-2) and the Record Management System (RMS, what would be like a file based record management system) were part of the library of system calls, the implementation operated within the kernel.
The VAX processor in 1978 had five operating modes, and putting aside PDP-11 compatibility mode, those were in the onion-layer model User, Executive, Supervisor, and Kernel. This was the first hardware processor to put into play the concepts we use today *EXCEPT* that it was totally enforced by hardware.
That includes an execute bit for page mapped memory. DECADES ahead of anyone else doing anything like that. /history
E
MacOS is based on Mach microkernel yet somehow its Darwin kernel is mostly monolithic. What gives? Perhaps microkernels made too many difficulties for practical use?
Don't let your ignorance get in the way of your mouth, either.
Having spent several thousand hours of my life dredging through Darwin's kernel interfaces, I can tell you the beating heart of Mach, the actual microkernel inside of MacOS, is literally dwarfed by the monstrous amounts of monolithic BSD and Mac bolt-ons.
In the end, I found the Mach aspect of Darwin served little purpose beyond making it more annoying to work in that Kernel. It sure didn't slow me down in my task of modifying the Kernel's page tables from user-space on an iPhone.
I love it when people who have no idea what they're talking about make such confident assertions.
NTOSKRNL runs its filesystems, object manager, executive, etc. in kernel space. In what way was this ever a microkernel design by any commonly accepted definition of the term?
While monolithic kernel design results in more code being given access that do not need, it also mandates a homogeny of code for provided services. This help ensure oversight of critical sections of code that could otherwise be poorly implemented, left unreviewed or have high implementation fragmentation.
Microkernels are technically safer designs but the culture of code review is equally important.
Anons need not reply. Questions end with a question mark.
Security isn't just confidentiality. It's Confidentiality, Integrity, and Availably (CIA). If the machine isn't running, it isn't provide secure services to the users.
The micro-kernel architecture ala Tanenbaum fails the security requirement of Availability; micro-kernel systems don't provide what people need. People use Linux because the design works well for building what people need.
The problem with microkernels is the same as it always was, performance. Largely caused by the overheads intrinsic NOT having access to necessary data to perform some function and having to call out for it. Security auditing is a biggy there.
And if you think a microkernel is so wonderful, instead of doing pseudo-studies to prove they are so great, write one instead and prove it.
MacOS (formerly OS X, not the weird crap that preceeded it) was never a microkernel design. Nor its Mach-based NEXT/OPENSTEP predecessors. Same goes for Tru64.
Let's get this clear: Any operating system that has filesystems or network stacks in kernel space is strictly monolithic. All this talk of 'microkernels' and 'hybrids' is tech press wank.
IIRC, the debate was really over whether or not an OS should span different system processors to provide users with a similar experience/capabilities rather than just concentrate on the latest processors with a specific operating model. I don't see how it applies to the security debate of today.
I would consider the '86-'286-'386 to be different processors because of the 16 bit unprotected page ('86) versus 16 bit protected ('286) and 32 bit protected and flat ('386). The Minix micro-kernel was custom to each processor family and provided the ability to run apps on different systems. Linux was designed for the '386 (and follow on processors), ignoring the previous versions of hardware and making the assumption that anything less than the '386 was going the way of the dinosaur.
Regardless of the approach, don't forget that 25+ years ago, networking was quite primitive - most home users were using telephone line modems and businesses had closed networks (if they had them at all). Lynx was the web browser of choice (Mosaic was still a year or two away). Network/computer security was in its infancy (Sandra Bullock's "The Net" was a few years away). Email barely existed (I was working at IBM at the time and was able to get "myke@ibm.com" without anybody questioning it or there even being standards applied to email accounts).
So, I don't think you can say that if Tanenbaum won Linus over to the microkernel (as well as Microsoft and other vendors) there wouldn't be the security concerns of today. I can't see how potential security flaws (which would be obvious by people looking at it from a contemporary eye) would have been avoided as the software stack of 1992 evolved into the stack of today if the microkernel approach was taken then.
Mimetics Inc. Twitter
This is academic until we have solid open-source operating systems based on a microkernel fit for general use - and we're almost there.
Genode (https://www.genode.org) is a really interesting project, a microkernel OS wherein the subsystems and policies are set up for resiliency and security. It actually can run on Linux, but it also works in conjunction with a variety of the L4 microkernels which go a long way towards solving the overhead problem characteristic of microkernels. It does seem to blur the line between hypervisor and host OS, but it seems awfully promising as a pragmatic response to the microkernel vs. monolithic debate.
In fact, I don't know why we even mention HURD when Genode is so far along.
https://en.wikipedia.org/wiki/...
http://michaelsmith.id.au
Web browsers rival operating systems in size and complexity, and are also hopelessly insecure. The main problem, shared with microkernels, is that the protection mechanisms available in common hardware don't allow efficient or convenient communication between protection domains, which are tied to address spaces. In order to cross the boundary, the address mappings must be flushed and reloaded, or at least manipulated, which are both very expensive operations. This makes any IPC very expensive, so the preferred means of communicating is by sharing memory, and for convenience and performance, nearly everything ends up in the same address space. Thus, the inevitable compromise of any part of these monolithic kernels and applications, is a compromise of the whole.
Without better hardware mechanisms for protection, that allow for efficient protection within the kernel and applications themselves, effective security will remain illusory. The furious and endless effort will continue in a futile attempt to hold the line against the flood of exploits. It is an intractable problem, unless we can shrink the protection domains to contain the effects of inevitable breaches. Capability-based addressing as with CHERI offers one approach, and the Mill architecture offers another. (see the Memory, Security, and IPC talks specifically.) Each represent a different set of trade-offs, which will limit applications. In any case, it is an area that needs work, so if there really are any nerds left on Slashdot, get to it, or at least help fund such efforts.
Apple's first attempt to get an OS running on Mach was, of all things, a Linux port. I don't think the code has been updated since the 2.x kernel series, but if it were to be resurrected, then perhaps there's less of a need to "move on" than the article's author believes.
Maybe you were thinking of VMS?
http://michaelsmith.id.au
Can you show us those cameras have no security hole punched in?
Could you please show us the code?
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
> Looks like even Microsoft did something right with their micro kernel design.
Except their userland is crap. So that negates all of the benefits of the microkernel.
A Pirate and a Puritan look the same on a balance sheet.
Looks like even Microsoft did something right with their micro kernel design.
Uhm...
...a monolithic system, such as Linux, Windows or MacOS...
Hell, they even moved graphics subsystem and a web server into kernel space.
Ezekiel 23:20
Doesn't exist? Micro kernels have to existed since 1969. They were a fad, a buzz word, in the early 1980s, like block chain in now. Then again in the 1990s, a resurgence of micro-kernel articles in the trade mags, and academic research. Some of the largest companies tried micro-kernel. They found out it doesn't work. The services that run in kernel mode, within the kernel address space, on all successful kernels are there for a reason. Multiple separate kernel THREADS work, and even a monolithic kernel like Linux has separate kernel threads.
What eventaully happened to achieve many of the goals of micro-kernel advocates, using some of the same ideas, is supervisors. Hypervisor's can be pretty small (or very large), and run a kernel as a process (not many processes) on top.
> from people who know even less than you do.
One of us is a kernel developer, the other thinks micro-kernels (many of them, btw) don't exist.
I enjoy talking to someone who has a different point of view than I, but next time you come to insult me please bring a clue. I see you don't have one today.
Will a microkernel mitigate application-level exploits? No. And really, the application level is the important level because the OS itself is a pretty useless source of user data.
Will a microkernel prevent a certain class of exploits? Probably. But if the platform is unsuitable for applications, then the question is moot.
Maybe they want to commercialize Mach 3? Mach 3 was supposed to be BoBW, but apparently nobody actually believed that.
Utterly irrelevant to bring up a little embedded OS fit for cars and blackberries and compare it to Linux. You have no point,
You are misinformed. Google Fuchsia is being designed for embedded applications, mobile devices and computers.
It may very well replace also those closed modified Linux boxes used internally.
That is the last thing I would think of. I would first printout that Linux is emphatically not a microkernel and Linus would never, ever concede that he was wrong in the micro vs macro kernel argument so that will not change. No, the first organisations I would think of would be GNU (HURD), FreeBSD, Apple (OS/X) and others.
Congratulations on finding one oddball application for which someone decided to use a micro-kernel. Specifically where it's not a general-purpose computer, performance doesn't matter, and there's no need to run more than one application at a time.
The next time I'm trying to build a slow as hell access KVM on specially designed hardware, I'll consider a micro-kernel. Only, of course, if I can't use a GPL kernel because I'm trying to keep everything secret.
It lives in a very, very complex sandbox, with a huge attack surface. But it is just as much an installed app as anything else.
What is needed is Secure HTML. It would not support everything that flashes and spins. No JavaScript. Not much CSS. Very limited interactions with non-origin sites. Such a thing could be made reasonably secure, and still support the all-important Material Design.
But nobody cares.
As to an "App" having access to all a users files, you are thinking too much of *nix. The world changed when Apple introduced basic sand boxing in IoS. It is long over due that I should be able to easily run installed Linux apps without giving them control over everything that I own.
As to micro kernels, it would seem that they are maybe 10% slower. And nobody wants an operating system that is 10% slower just because it is more secure.
The final piece is the C/++ programming language. And ungly mess that actively encourages buffer overflows and other joys. Most of the code in an O/S can be written using something decent. All the non-micro kernel bits anyway.
Windows NT was Cutler's next time around. MacOS X (technically Mach) was Tevanian's first time.
Pretty interesting how things worked out.
So they found that a number of exploits against the Linux kernel would fail against a micro-kernel. Their conclusion: micro-kernel is safer.
Wait a moment: how do they rule out that new exploits would come up expressly targetting the micro-kernel and failing against the monolithic kernel?
Strong logic.
So STFU - Linux is the worst - get over it.
No, QNX is not fit for general purpose OS or server, it's a real time OS. Corporations are not serving internet and middleware and database from QNX servers.
It is not fit for desktop, though yes some here have loaded it onto desktop proving exactly nothing, it's a toy. No one here is posting from QNX desktop and they're not using QNX desktop at work.
... resulting from monolithic design problems:
https://linux.slashdot.org/com...
https://www.mail-archive.com/f...
https://slashdot.org/comments....
"Some companies have long considered Smalltalk their "secret weapon" because they could upgrade their systems at least at the application level while the applications continued to run. I guess I've been in computing so long and seen much better innovations like QNX and Smalltalk get passed by in favor stuff like Linux and Java that I guess I don't expect good innovations to be adopted except perhaps decades later. Anyway, I still have a lot of respect for Linus and his accomplishments in bringing a community of people together to do FOSS software. A free Linux is better than an unfree QNX in that sense. Nobody is perfect. And obviously a lot of people here are defending Linus' choice of strong language. Yet, I can't help but feel that the reason Linus is angry, and fearful, and shouting when people try to help maintain the kernel and fix it and change it and grow it is ultimately because Alan Kay is right. As Alan Kay said, you never have to take a baby down for maintenance -- so why do you have to take a Linux system down for maintenance?"
Anyway, nice to see this discussion come up again years later related to a more detailed analysis.
The reason I did not want to use Linux in the first place in the 1990s was because Unix was obviously an out-dated design compared to microkernel-based QNX etc.. But in the end the large community adopted it and so I did too. But I did not have to like the unfortunate core technical choices that traded off things like security, upgradability, understandability, and consistency for a claim to be a bit speedier on certain hardware.
Sort of like Intel's hardware design choices to emphasize speed over security are also now coming home to roost.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Minix?
https://en.m.wikipedia.org/wik...
Minix?
https://en.m.wikipedia.org/wik...
If Firefox runs under a different user, it cannot access your main profile.
C:\Windows\System32\runas.exe /user:firefox /savecred "C:\Program Files (x86)\Mozilla Firefox\firefox.exe"
Thanks for your thoughtful post.
The thing is, it's not about time to market. It's about time to execute an operation. Fifty years is enough time to bring something to market.
Memory access takes half a tick, Double Data Rate RAM (DDR) transfers data on the rising and falling edge.
Context switching is an order of magnitude slower, theoretically, and two orders of magnitude in real life. As Meltdown and Spectre remind us, when switching context you have to flush all the caches, meaning everything is going to cache miss after a switch.
Microsoft and Apple didn't give up on the micro-kernel idea because they wanted to get something out the door, they gave up on that idea because it does not work. Operations take around 50 times longer to complete, especially on larger multi-tasking systems. Anywhere performance matters at all, message passing fails miserably.
It's not a matter of "It's always been that way". In fact the opposite - the point is they DID try micro-kernel, many people tried it, and every time they found out (again) that it does not work.
It reminds me of the policy debates that come up and people want the federal government to try policy X. Someone points out that because policy X sounds like an interesting idea to try, it WAS tried in California, New York, Chicago, the UK, and elsewhere. Everywhere it was tried, the effect it had was exactly the opposite of what was intended. Yet some people can't give up on evangelizing enforcing policy X on the federal level, because it sounded good. Yeah maybe it did sound interesting, that's why numerous people tried it, and it turns it it did not work. Time to try things that can work well.
Context switching with core pinning on a 12 core, hyperthreaded processor takes several microseconds in total. 1600ns for the actual switch, then a multiple of that for for LLC, etc. Contrast in-context memory access of 1ns with cache hit, up to 12ns for cache miss. Micro-kernel with many cores is 100-1,000 times slower.
So then maybe you start making changes to the micro-kernel model in order to have it work well on physical processors. Maybe you ask "how CAN we use SMP to separate concerns, putting aside any old assumptions from ukernel religion and instead trying to accomplish the goals by using many cores effectively?" Starting with the goals of micro-kernel evangelists and then going where the facts take you, you end up writing a hypervisor.
Have you seen the Combos snack food? It's a little tube of cracker or pretzel filled with cheese flavored filling, or pizza flavored filling. They are sold at gas stations next to the chips and crackers. That idea started out as a croissant stuffed with crab meat. Through product development, it became something rather different - ans successful.
It's not that what the ukernel advocates we're trying to accomplish was wrong, or even that their implementation was completely bananas. It's just that as you revise and extend the micro-kernel ideas to have them work well, it develops into virtualization, with what was the kernel becoming the hypervisor. That works well. What doesn't work is a religious attachment to the initial ideas of how a micro-kernel could be implemented and how it might work. Those were just ideas, like the croissant with crab meat idea. Developing it into something that works requires letting go of the emotional attachment to crab.
Hmm... cherry pick much? Lots of critics justifying calling MacOS monolithic despite the Mach kernel, but not a peep about OpenBSD, which IS monolithic and which IS the most secure OS
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
> Describing it as more of a hypervisor is along the lines of what I was thinking; although having a full independent kernel on each core is a bit much I think. Perhaps a very limited kernel, without drivers but with limited memory management capabilities is in order.
"Without drivers" is exactly how I use virtualization, and how I believe it's most often done at scale. The guests use virtio, not hardware drivers. The kernel is effectively divided into one thing that ONLY handles hardware, and completely separate thing that is ignorant of the hardware but responsible for scheduling user processes and that sort of thing. The "hardware kernel" is the hypervisor. The other thing that provides kernel-like userland is the guest kernel. The CPU runs the guest in ring 1 (guest mode) rather than ring 0 (supervisor or kernel mode). We CALL it a "guest kernel", but the CPU doesn't run it in the same mode as an actual kernel. The hypervisor is the real kernel, as far as how the CPU treats it.
What we find is that the kernel (or kernel-like thing) performs operations over and over that don't require direct access to CPU registers, but do require one part of the kernel to talk to another part. For efficiency, those needs to run in the same process space, using memory accesses. In other words, that chunk needs to be monolithic. But because it doesn't need direct access to CPU registers, it doesn't have to be THE kernel. It can be a monolithic guest kernel that is oblivious to the hardware, so it doesn't need drivers, just virtio.
Linux is still a microkernel.
DirectX began in the Windows 9x series. It was a way to bypass the Windows imaging and windowing models, and blit direct to hardware. Programmers at the time laughed and said, "Oh yeah, DOS!"
"Flyin' in just a sweet place,
Never been known to fail..."