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.
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).
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.
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?
Although I agree with your post's subject, I think the argument here is the degree to which things can be successfully hacked. I believe they also mischaracterize macOS... as it's a Darwin branch of BSD and much tinier in size (the kernel, not the kexts) than Linux or Windows 10/2016.
In this ideological world surmised by someone who I believe has an agenda of their own (the cited paper). Any kernel with popularity is going to get bashed and hacked and crunched and messed with; this is inevitable. The author cites no evidence that a non-monolithic kernel with a comparable number of installations is going to be any more secure. Nada.
A nano kernel is the answer? If one is deployed, it's not very useful and has to be aided by other apps, a design forced largely by the chipset makers. If you look at motherboards 20, then 10 years ago, you'll note that the amount of discrete components is shrinking rapidly, replaced largely by SoCs.
Worse, kernel design has been somewhat forced by the whimsy of the Intel/AMD/NVidia cabals. In 2008, a decade ago, we had laptops, desktops, and servers. There were some portable devices, but diffuse and there were numerous architectural battles going on for how they would turn out.
They turned out like this: crazed IoT, myriad phones, laptops, desktops, pre-made servers, DIY architecture servers, based on Intel/AMD/NVidia, along with a minor share of IBM chips, and a superfluity of ARM versions, some of which are compatible.
If you're a developer, learning machine language is not high on your list for most. And so porting your valuable app to a target device is now what 1) enables that hardware architecture with functionality and 2) common OS support provides a foundation for your app to run. The chicken-and-egg problem is that a new family of devices needs a common substrate for apps to work. No apps, no functionality, no sales.
The argument about the # of CVEs justifying a monolithic kernel or something other than a monolithic kernel is more or less moot.
All this said, Intel and AMD and to a lesser extent ARM licensees are in deep crap because there are very serious fundamental architectural problems with their current designs. How many CVEs make up for that?
I believe the paper cited is deeply flawed.
---- Teach Peace. It's Cheaper Than War.
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.
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.