A recent article on ThreatPost seems to provide unxepected evidence of kernel software being attacked :
I'll just caution that most of the article is about spammers accidently giving away their actions. However, one bit that caught my eye is copied below, from a chat log :
Sean: [...] then we're stuffing it into the kernel
Sean: [...] stuff as much packet data down their throats as possible until they disconnect you "
This discusses exploiting a kernel vulnerability, possibly within a comms driver or TCP stack. The objective is to place the attacker's code in the kernel and then execute that code with a high privilege (root essentially). What happens next will vary, depending on the purpose of the attack, but in this case it seem to be about exfiltrating masses of sensitive information from the chosen target.
It would be far harder to perform the same task (perhaps even impossible) if the target machine was running a microkernel. A microkernel reduces to a minimum how much code is allowed to execute with high privilege. Whatever code/functions remain in the kernel can then be reviewed much more easily for code correctness. It's a really simple idea - if code is written correctly, it can't be attacked.
If further proof was needed that the traditional (monolithic) kernel of a browsing device was a risk, then consider these facts :
- in the 2000s, Apple made a huge efforts to create a kernel that was almost as secure as a microkernel. They then deployed it, fairly successfully, in various new products and also in OS X.
- the Qubes project took a different approach by implementing a tiny secure hypervisor and running a distribution of GNU/Linux on top of that
- The Minix 3 project attempted something different again - they wrote an entirely new microkernel, from scratch
But, typically, when you write an OS from scratch, you have no drivers. This can sometimes be overcome by creating a layer of software glue that connects certain existing drivers to the brand new kernel (or microkernel). The Minix 3 project did this, giving it access to NetBSD userland and drivers. Those drivers were originally executing in the NetBSD kernel.
Within the computing industry, there's clearly a lot of interest in microkernels, and not just for deployment as browsing devices. For example, both KasperskyOS and Redox hope to gain deployment of their new OSes as the hub of ultra-secure network nodes. In this regard they are joined by SourceT. All 3 of those have microkernels. (SourceT is already out there and running on IA-64 architecture. Could be a hint there.)
And, returning to browsers, it's my belief that you could still run QNX on a desktop PC, if you were to ask the owners nicely. (Research required here).
Then we had the Aug 2016 announcement from Google, who are building a new minikernel, one which is designed to support both smartphones and desktops. Software engineers, who are known for having prior experience with this technology, are running the project, so success is strongly anticipated. However, it's a minikernel because it hasn't been made as small as possible, this time. The one driver that's being left in the kernel - the graphics driver - will need to be hardened (e.g. be made small and free of vulnerabilities).
It's worth noting that whilst almost everyone else is looking at microkernels (of some form, including MS), the Linux project is not. And I also see no current plans for OpenBSD or FreeBSD to investigate new kerneks either. Possibly they pin their hopes on re-using whatever NetBSD achieves through Minix 3. That would be fairly typical for the various BSDs.
Linux can run on top of different types of hypervisor and, in doing so, this gives it a limited amount of protection from its security bugs (which seem to have famously long lives). Qubes is one example of how you can change the architecture of Linux and reduce the risk of privilege escalation. L4Linux would seem to be another solution. However, once the GNU project has released a (much delayed, early-architecture) microkernel of its own, it will be interesting to see the adoption rate of this microkernel (Hurd, as it is fondly known). It ought to be an option in Debian and GuixSD distributions, as a minimum. Present-day attacks on monoliths (such as Linux) will increase which suggests to me that there will be some kind of response from the industry.
My suggestion for further contributions to this thread would be as follows :
- add to the initial list of microkernels
- document new information for microkernels, as it becomes available
(for example what are the timescales for GuixSD/Hurd and Genode ?)
- (maybe) discuss other CPUs and any effect that they may have on microkernel design
- document the acccepted generations of microkernel design ( 1, 2 and 3 ? )
There's really only one issue that I would suggest not be discussed here and that's whether the design decisions made during the life of Linux were correct, either at the time, or in hindsight. In 2017, the ability to hack endpoints has reached a level that would not have been predicted, even just a few years ago. Separately, we all know that CPU power has grown massively, so the landscape is different. There are places where you can read about the original arguments over whether Linux should have been a microkernel or not. Interesting history but that's a good place to leave them :-)
Genode looks like it has fantastic prospects but I seriously doubt whether I will be able to boot a PC off this OS via a Live CD before 2020. Changes of direction in the RoadMap suggest differing, unresolved opinions within the development group. I know that I would like to use it. Why not give it a marketing boost guys - get lots of people using it ! Genode has the ability to provide a third kernel option for GNU distributions, eventually, perhaps through seL4, the formally verified microkernel.
I haven't discussed every microkernel that I'm aware of, so here are brief mentions of a few more: HelenOS, Robigalia, Rux and BlackBerry 10.
And since we now have Qubes (for AMD64 anyway), is there a good, fairly technical review of Qubes OS ?
Some project links :
I found this independent review of Qubes to be quite useful and it cites an example platform that you could use :
edit: grammar and add a few bits
Edited by palerider2, 09 March 2017 - 07:33 PM.