DaveK’s Embedded Security Blog
Comment
sharps_eng
@Hari: Linux COULD be tuned, yes, but that is a conditional, assuming great ...
davek_ghs
No disagreement - a microkernel is not, by itself, enough for a secure system. ...
Monolithic stupidity
Dave Kleidermacher
11/18/2011 12:13 PM EST
Microkernel vs. monolithic? Duqu, a Stuxnet-like worm, proves the monolithic operating system is dangerous.
Over the years, designers of operating systems have argued the merit of the two major approaches: microkernel and monolith. Microkernels: simple TCB, push OS services (networking, file systems) into user mode apps. Monolithic: run most everything in the kernel. The most famous public argument occurred for a period of years starting in 1992, between Linus Torvalds and Andrew Tanenbaum, OS professor and researcher. I admit the debate was less clear two decades ago when hardware performance promoted the kitchen sink approach. If someone were launching a new OS design today, it would be ludicrous not to use a microkernel.
While Linus finally gave an inch: "True, linux is monolithic, and I agree that microkernels are nicer. From a theoretical (and aesthetical) standpoint Linux loses," he has continued to assert that monoliths are required to achieve adequate performance. He’s simply wrong. Continuing to claim that monolithic design is superior is like the Church of the 1630s hanging on to the Aristotelian cosmos, condemning Galileo for heliocentrism.
By now you’ve probably heard of Duqu, a Stuxnet-like worm enabled by a Windows flaw in…font parsing! From the Microsoft advisory: "An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode. The attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. We are aware of targeted attacks that try to use the reported vulnerability." The National Vulnerability Database has dubbed this CVE-2011-3402, assigning a severity rating of 9.3 (high).
As reported in Slashdot, "Many file formats like HTML, Office, and PDF support embedded fonts, and in NT4 and later fonts are parsed in kernel mode!"
You heard that right. Massive font code parsed in kernel mode. One flaw, and you’re toast. The Duqu attack is a direct result of Windows’ monolithic design.
This ignominy will surely engender a design change, right? Wrong. We are hopelessly dependent on monolithic operating systems (Linux, Windows, OSX). There is simply too much legacy, and it is growing--rapidly--every day, driven by the inexorable digitization of our world. Monolithic design in no way precludes awesome bells and whistles.
As passionate as I am about this microkernel vs. monolithic polemic, I also predict the debate will subside over time and become mostly irrelevant. Modern hardware features (some of the same ones that have made microkernels practical)--system virtualization support, application-specific accelerators, and multicore--also make it easy to run monoliths and microkernels on the same system at the same time. So we need not debate which design is better; we must be smart enough to use each one for its relative advantages. I talk about this dichotomy in some of my other blogs...
Dave Kleidermacher is CTO of Green Hills Software. He writes about security issues, sharing his insights on techniques to improve the security of software for highly critical embedded systems.
Over the years, designers of operating systems have argued the merit of the two major approaches: microkernel and monolith. Microkernels: simple TCB, push OS services (networking, file systems) into user mode apps. Monolithic: run most everything in the kernel. The most famous public argument occurred for a period of years starting in 1992, between Linus Torvalds and Andrew Tanenbaum, OS professor and researcher. I admit the debate was less clear two decades ago when hardware performance promoted the kitchen sink approach. If someone were launching a new OS design today, it would be ludicrous not to use a microkernel.
While Linus finally gave an inch: "True, linux is monolithic, and I agree that microkernels are nicer. From a theoretical (and aesthetical) standpoint Linux loses," he has continued to assert that monoliths are required to achieve adequate performance. He’s simply wrong. Continuing to claim that monolithic design is superior is like the Church of the 1630s hanging on to the Aristotelian cosmos, condemning Galileo for heliocentrism.
By now you’ve probably heard of Duqu, a Stuxnet-like worm enabled by a Windows flaw in…font parsing! From the Microsoft advisory: "An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode. The attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. We are aware of targeted attacks that try to use the reported vulnerability." The National Vulnerability Database has dubbed this CVE-2011-3402, assigning a severity rating of 9.3 (high).
As reported in Slashdot, "Many file formats like HTML, Office, and PDF support embedded fonts, and in NT4 and later fonts are parsed in kernel mode!"
You heard that right. Massive font code parsed in kernel mode. One flaw, and you’re toast. The Duqu attack is a direct result of Windows’ monolithic design.
This ignominy will surely engender a design change, right? Wrong. We are hopelessly dependent on monolithic operating systems (Linux, Windows, OSX). There is simply too much legacy, and it is growing--rapidly--every day, driven by the inexorable digitization of our world. Monolithic design in no way precludes awesome bells and whistles.
As passionate as I am about this microkernel vs. monolithic polemic, I also predict the debate will subside over time and become mostly irrelevant. Modern hardware features (some of the same ones that have made microkernels practical)--system virtualization support, application-specific accelerators, and multicore--also make it easy to run monoliths and microkernels on the same system at the same time. So we need not debate which design is better; we must be smart enough to use each one for its relative advantages. I talk about this dichotomy in some of my other blogs...
Dave Kleidermacher is CTO of Green Hills Software. He writes about security issues, sharing his insights on techniques to improve the security of software for highly critical embedded systems.
|
|
|
|
|
Navigate to related information
przemek
11/23/2011 3:04 PM EST
he problem with Mr. Kleidermacher's argument is that kernel vulnerabilities aren't the main security threat any more. Advanced capabilities in modern system are outside of the kernel, even more so in microkernel designs, and vulnerabilities simply follow the complexity. After all, I don't care whether my password was stolen by a kernel-resident keylogger or browser Javascript vulnerability. I think Mr. Kleidemacher actually agrees with that, based on his concluding paragraph---so I invite him to take a holistic approach to security, rather than implying that the OS vendor is blameless because the vulnerability wasn't in the kernel.
In theory, microkernel does potentially allow for more granularity and modular security, but only after such measures are actually put in place, with the resulting further performance hits. Otherwise, it's not a valid comparison, especially since similar modular security can be deployed on monolithic kernels, eg. via SELinux.
Finally, let's remember that the example used in the article, Windows, started as a microkernel, and devolved into its present monolithic form because of a perceived performance need, so that particular failure is really indicative of the well-known security blind spot of one company.
Sign in to Reply
davek_ghs
11/30/2011 1:35 PM EST
No disagreement - a microkernel is not, by itself, enough for a secure system. You can place a million lines of code in a single process on top of a secure microkernel... However, my argument is that you cannot build good security on the big monolithic operating systems. A secure microkernel is a requisite foundation for secure systems. The same principles that drive use of a microkernel - minimization of complexity, componentization, least privilege principle - must be applied throughout the system. Microkernels enable, but do not by themselves guarantee, that developers will do this!
Sign in to Reply
cdhmanning
11/24/2011 9:12 PM EST
Well sorry to sink your boat, but microkernels don't really protect against worms etc.
Microkernels do provide some protection against crashing (eg. a buggy driver can crash and restart without taking down the whole running OS). But they don't necessarily prevent running worms.
Typical microkernels run all OS processes in a privileged mode which allows worms to propagate.
Linux pretty much does have the flaw you mention because the Linux kernel community understands the foolishess of running PDF converters in the kernel and just would plain not do it.
Why Microsoft would do such a thing is beyond understanding. Perhaps their process switching is too inefficient and the code was stuffed into the kernel for performance reasons.
It is somewhat funny that while Linux started off monolithic, there has been a tendency to more towards more service daemons - slightly towards microkernels.
Sign in to Reply
davek_ghs
11/29/2011 1:42 PM EST
For some reason, you (cdhmanning) like to denigrate all of my blogs. I don't know who you are or what your agenda is, but it would be nice to see some constructive and informed criticism from you sometime.
In this case, you're way off base. Microkernels do not execute processes in privileged mode. The whole point of a microkernel is to execute processes in user mode. Your comment makes it obvious that you have no practical experience with microkernels, yet you opine here.
Linux may not have this specific font flaw, but that wasn't the point: Linux is monolithic and has plenty of other flaws. If you want to debate this, let's go. I'll just point you to the National Vulnerability Database. Linux has many things going for it, and I'm a fan of those things (I use it myself for development every day), but it does not have a good, modular security design and it never will, no matter how vociferously you argue otherwise. Your comments will be far better received in this community if you can demonstrate a higher level of knowledge and balance.
Sign in to Reply
eembedded_janitor
11/29/2011 7:02 PM EST
I don't have any special mission to denigrate your blogs.
While it is indeed possible to use microkernel architectures to help make an OS secure, this is not always the case.
WindowsCE, for instance, is a microkernel OS and it has absolutely no worthwhile inter-process security. So clearly microkernel, on its own, is no magic ingredient.
Windows NT (ie. XP, Vista et al) started off as a microkernel, but became more monolithic with time.... and we all know what a tragedy that is.
I too use Linux on a daily basis, but I am no rabid Linux fan. I am not blind to the various faults that Linux has.
Security issues on Linux systems very seldom involve kernel vulnerabilities. They generally involve user space vulnerabilities due to poor application permission design. I fail to see how any OS can protect against that. Run a web server on any OS of your choosing and it will be compromised if the passwords etc are not controlled.
As for balance, well I'm not the one posting thinly veiled sales material!
I am always willing to learn and would be very interested in you providing me with a URL explaining how a user-space file system can be trusted with system files. Or how a user-space networking layer can be trusted to not fiddle with network traffic. I would find that most interesting.
Sign in to Reply
hari.tadepalli
11/27/2011 1:03 PM EST
test
Sign in to Reply
hari.tadepalli
11/27/2011 1:16 PM EST
Arguments offered by Mr. Kleidermacher is more at a polemical level than a technical level. Logically speaking, simplifying things and minimizing non-linear interactions has more potential to guard against secuirty flaws - this is well conceivable for a purely embedded applications where the designers have fully well scoped/specified the inteded use cases and interactions well in advance. For more general purpose OSes, key system resources like processor time (scheduling), memory mangement, interrupt/IO address space management are better handled by a central entity. It always peplexed me as to why application level computation tasks such as fonts, cryptography are handled by kernel level modules. For perfomrance critical applications, it is possible to tune Linux to beat at least 90% of what is allowed by hardware capacity, versus a possible 100% engineered into a dedicated (ukernel based) application after a considerable effort. Best practices for security do recommend minimally built configuration. Best thing is, Linux could be customized infinitely without losing its architectural traits and well known user interfaces.
Sign in to Reply
sharps_eng
11/30/2011 2:51 PM EST
@Hari: Linux COULD be tuned, yes, but that is a conditional, assuming great talent, knowledge and perseverance (=funding). When those resources are in limited supply, a commercial RTOS should put you miles further down the road in the same timeframe, at a cost that should equal or match the additional labour cost of the Linux solution.
I say SHOULD because not all RTOS systems stay up to date, neither do they provide the best support; and many have not charged enough to stay viable.
There is a big difference between the programmer who is happy to write tight code on top of an RTOS, and a wannabe system programmer who wants to get down and dirty and produce a better OS. Each has their place, and each has their own self-interest, so managers, take care which one you consult about such issues!
Sign in to Reply