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.
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.
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
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.
Linux did NOT start out as an embedded OS.
Linux did NOT start out as real time operating system.
Huge difference between the two, not for the same purpose nor the same job.
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.