At 04:09 UTC on July 19, 2024, CrowdStrike released an update for its Falcon sensor software. A defect in the update caused 8.5 million Windows computers to crash simultaneously. Half the S&P 500 runs CrowdStrike. Flights were grounded worldwide.

I was in an airport terminal when my flight got canceled. So I started thinking about kernels.

Key Takeaways

• The CrowdStrike incident demonstrated the risks of kernel-level access—one bad update crashed 8.5 million systems globally.
• Different kernel architectures offer varying trade-offs between performance, security, and stability.
• Multi-tier kernel designs could limit the blast radius of security software failures by implementing privilege separation.

My flight was only delayed two hours initially, but I felt for those whose journeys were more severely disrupted. That sympathy dissipated when Delta canceled my return flight four days later.

The Incident

The root cause was a problematic modification to a configuration file, Channel File 291, which handles screening named pipes. This led to an out-of-bounds memory read, causing an invalid page fault. In simpler terms: the program tried to access memory it shouldn't, causing a crash. The update was forced onto millions of systems via auto-update, rendering them temporarily useless.

Like many security products, CrowdStrike's Falcon sensor operates at the kernel level to provide robust system protection. This level of access introduces the risk of an application crashing the entire system (or worse), and after that occurred on July 19 and I was left to my own devices in the airport terminal, I started thinking about the variations of kernels out there and what could be done to prevent this from happening again while also realizing I was severely understudied on the topic.

Kernels

A kernel is the core of an operating system, providing essential services to other programs. There are many different types of kernels, including monolithic, micro, hybrid, exo, and nano - all with their pros and cons.

Type	Description	Pros	Cons
Monolithic Kernels	Run all OS services in kernel space	High performance, efficient	Large size, potential system-wide crashes
Microkernels	Most services run in user space	Enhanced stability and security	Lower performance
Hybrid Kernels	Balance between monolithic and microkernels	Optimized performance and modularity	Increased complexity
Exokernels	Gives programs direct control instead of relying on kernel	High performance, efficient	Increased complexity
Nanokernels	Offer bare minimum services for hardware management	Minimal attack surface, specialized	Limited functionality, not general-purpose

Multi-Tier Kernels

Given my limited expertise in this domain, I figure a multi-tier kernel architecture can theoretically prevent higher-level applications from having unrestricted access to the kernel, thereby enhancing system stability and security.

• Core OS functions operate at the lowest, most privileged level.
• Essential drivers and security software run at a slightly higher level with restricted access.
• Application-level software operates at the highest level with minimal kernel access.

During my brief research, I found academic research discussing three different multilevel security kernel architectures. The authors rightly conclude that the choice of architecture depends on the specific requirements of a system or deployment scenario.

The goal is to prevent a single issue from compromising the entire system or affecting core OS functions.

One clear benefit of implementing a multi-tier approach is that you could facilitate a least-privilege architecture, potentially limiting the impact of vulnerabilities or bugs, such as the one in Falcon's Channel File 291.

SimpleOS: A Prototype Implementation

After learning so much about kernels, I decided to prototype one. This represents an initial exploration into kernel development, with plans for future iterations. Since this is my first kernel, I made it monolithic to understand standard practices.

To start, SimpleOS features the following:

1. Monolithic kernel design
2. Interrupt handling system with custom handler support
3. Memory management with paging and simple heap allocation
4. Basic multitasking using round-robin scheduling
5. Essential x86 structures (GDT, IDT) and initialization

The full source code is available on GitHub, and stay tuned for upcoming PRs for SimpleOS and future kernel projects that further explore the multi-tier ideas mentioned above.