Study Confirms That Microkernel Is Inherently More Secure

The bigger the software footprint, the more bugs and vulnerabilities. Given this, it makes sense that a monolithic operating system like Linux would contain more vulnerabilities than a microkernel-based operating system like the QNX® Neutrino® Real-Time Operating System. A 2018 study by Simon Biggs, Damon Lee and Gernot Heiser analyzed the critical security bugs in Linux and concluded that “96% of critical Linux compromises would no longer be critical with a microkernel-based design” and that at least 29% of the critical vulnerabilities would be eliminated entirely.

What is a Monolithic Architecture?

A monolithic kernel runs all operating system components in kernel space; it includes all device drivers, file management, and networking and graphics stacks. Only user applications run in user space.

Although a monolithic design protects a kernel from errant user code, it doesn’t protect it from errant kernel code. A single programming error (or successful exploit) in a file system, protocol stack or driver can crash a monolithic operating system.

Most software code is buggy, and unfortunately highly complex kernel code is no exception. Biggs et al. determined that Linux likely had 13,000 bugs at the time of the study, based on its multi-million source lines of code (SLOC) and an optimistic estimate of bug density of 0.5/kSLOC.

Smaller Kernel, Fewer Vulnerabilities

Kernel code has special privileges, specifically, access to the entire system. Bugs in kernel space create vulnerabilities for malicious actors to exploit. A smaller kernel reduces the amount of privileged code, which improves system security, functional safety and reliability: fewer lines of potentially buggy code have privileged access.

The Biggs study presents a stark confirmation of the arguments in favor of a microkernel architecture over a monolithic kernel architecture. The relative sizes of a Linux kernel and the QNX microkernel are an indication of a dramatic difference in the amount of privileged code each contains. In fact, in January 2020, the Linux kernel had around 27.8 million lines of code in its Git repository; with about 100 thousand lines of code the QNX Neutrino RTOS is 99.7% smaller.  

Advantages of a Microkernel Architecture

A microkernel operating system embodies a fundamental innovation in the delivery of OS functionality: modularity. The tiny kernel is a side effect. With a microkernel OS, the microkernel works with a team of optional cooperating processes that provide higher-level OS functionality. Critically, unlike with a monolithic kernel, these processes run in user space; that is, outside privileged kernel space.  

The microkernel architecture is based on the concept of least privilege. Only the kernel is granted access to the entire system. A microkernel OS like the QNX Neutrino RTOS encapsulates each application and OS service in its own isolated process space. The microkernel protects and allocates memory, and gives drivers and other OS services only the minimum privileges they need to perform their functions.

Fault containment through isolation and least privilege prevents errors and exploits from affecting other parts of the system. The only thing a component can crash is itself. Such crashes can be easily detected, and, since the kernel is unaffected, the faulty component can be restarted while the system is running with minimal impact on performance. In short, in the event of a kernel crash in a monolithic kernel system the only response is to reboot the system, while with a microkernel OS the system can usually repair itself to provide a much better mean time between failures (MTBF).

In summary, the security advantages inherent in a microkernel architecture include:

• Less code running in kernel space reduces the attack surface.
• Fault isolation and recovery support high availability: a failed system service can be dynamically restarted without a system reboot.
  
  

Why a Microkernel is Inherently More Secure, Safer, and More Reliable Than a Monolithic Kernel

The Biggs study examined all 115 critical CVEs (Common Vulnerability Enumeration, a popular vulnerability database) known to be present in Linux in late 2017, each vulnerability categorized based on how it would affect a microkernel OS. Of the critical vulnerabilities, a microkernel would eliminate nearly a third, and more than three-quarters would be at least partially mitigated, with the following distribution and examples:

• Eliminated by microkernel, 29%: For example, CVE-2015-4001, an integer signedness in a driver used by threat actors to crash the system. The authors conclude, “In a microkernel-based system, the driver would run as a user-level server in its own address space, and as such could not overwrite kernel memory and cause a system crash, information leakage or corruption. Furthermore, any code injection would only execute with the minimal privileges required by the driver.”
  
  
• Eliminated by formal verification, 11%: If the microkernel were formally verified, then the critical compromise would be eliminated. Page table management is a kernel function placed in this category, specifically, CVE-2014-9803, which mishandles execute-only pages allowing an application to gain kernel privileges. The authors determined that since the operation must be performed in kernel mode, it could occur in a microkernel, but not in a formally verified microkernel.
  
  
• Partially mitigated by microkernel (strongly, 17%, weakly, 38%): These critical vulnerabilities compromise an OS component, but not the whole system. CVE-2015-8961 allows users to gain privileges or crash the system. The authors conclude, “On a microkernel, the file system would be implemented as a user-level server, and this exploit would not result in a kernel crash.” However, a threat actor could read confidential files if the data were not encrypted. If files were encrypted, the key must not be accessible to the file system. If the application is designed to not trust the file system, though the attacker can crash the file system, the data remains secure.
  
  
• Unaffected, 5%: A microkernel would not have mitigated only 5% of the critical Linux CVEs.
  
  
• Unknown, 3%: Too little information for classification was available to categorize a few CVEs.

“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 21^st century security requirements,” conclude Biggs, Lee and Heiser. We at BlackBerry QNX agree.

QNX Neutrino RTOS – Proven Reliability in Hundreds of Millions of Embedded Systems

Thousands of companies deploy and trust QNX real-time technology to ensure the best combination of performance, security and reliability in the world’s most safety-critical and mission-critical systems. At the core of this offering is the QNX® Neutrino® RTOS, a full-featured and robust microkernel RTOS designed to enable the next-generation of products for aerospace and defense, automotive, commercial vehicles, heavy machinery, industrial controls, medical devices, rail and robotics and automation.

With the QNX RTOS, embedded systems designers can create compelling, safe, and secure devices built on a highly reliable RTOS serving as the foundation that helps guard against system malfunctions, malware and security breaches.

Learn more in the blog post How to Choose the Right OS for Your Embedded System: 10 Criteria for Success or visit the BlackBerry QNX website to explore the Ultimate Guide to RTOS.