Trust Nothing: RTOS Security without Run-Time Software TCB (Extended Version)

This paper presents a novel capability architecture and a corresponding Zephyr-based real-time operating system that achieves comprehensive security for embedded devices by fully disaggregating and isolating all software subsystems and peripherals, thereby eliminating the need for a run-time software Trusted Computing Base (TCB) without requiring hardware modifications.

The Gist

Imagine your embedded device (like a smart thermostat, a medical device, or a network router) as a high-security bank vault.

Traditionally, this vault has a Guard (the Operating System Kernel) who holds the master keys. The Guard decides who gets to open which door. The problem? If the Guard gets sick, tricked, or hacked, the whole vault is compromised. Furthermore, the vault has Delivery Trucks (peripheral devices like Wi-Fi chips) that drive right up to the vault. If a truck is hijacked by a criminal, it can smash through the walls and steal everything, even if the Guard is doing their job.

Current security systems usually try to protect against either the Guard or the Trucks, but rarely both at the same time.

This paper introduces Skadi (the new OS) and Bredi (the new hardware), a system built on a concept called Northcape. Their philosophy is simple: "Trust Nothing."

Here is how it works, using everyday analogies:

1. The "Token" System (No Master Keys)

Instead of a Guard holding a master key, imagine every single item in the bank (a file, a memory block, a driver) has its own unique, unforgeable token.

• The Old Way: You ask the Guard, "Can I open the safe?" The Guard checks a list and says, "Yes." If the Guard is lying or hacked, you get access.
• The Skadi Way: You don't ask permission. You simply hold the token. If you don't have the token for that specific safe, the door physically won't open, no matter how much you scream or beg. Even the "Guard" (the OS kernel) doesn't have a master key; it only has the specific tokens it was given for the task at hand.

2. The "Untrusted Guard" (No Trusted Kernel)

In most computers, the OS kernel is the "Trusted Computing Base" (TCB). It's the one thing you must trust. If it has a bug, you are doomed.

• The Skadi Solution: They break the OS into tiny, isolated rooms called Subsystems.
  • The Scheduler (who decides who runs next) is just a small room.
  • The Memory Allocator (who gives out space) is another small room.
  • The Network Driver is yet another room.
• The Magic: These rooms are mutually distrustful. The Scheduler cannot peek into the Memory Allocator's room. If the Scheduler gets hacked, the hacker is trapped in that tiny room and can't touch the rest of the bank.
• The Result: Once the bank opens in the morning, the "Guard" (the loader) locks itself in a tiny closet and throws away the key. The bank runs entirely on these small, untrusted rooms. There is no running software to trust.

3. The "Hijacked Delivery Truck" (DMA Protection)

Peripherals (like Wi-Fi chips) are like delivery trucks that can drive directly into the vault to drop off or pick up packages (Direct Memory Access). Usually, if a truck is hacked, it can drive anywhere.

• The Skadi Solution: The system uses a Smart Gatekeeper (the Northcape hardware) sitting at the entrance of the vault.
• When a truck (device) wants to enter, it must present a Token. The Gatekeeper checks the token.
  • "This token says you can only drop off packages in the Mailroom."
  • The truck tries to drive to the Vault? BAM. The gate slams shut.
• Even if the truck is a "Trojan Horse" (a malicious device), it can only touch what its token explicitly allows. It cannot read the bank manager's private notes or steal the gold.

4. The "Instant Switch" (Subsystem Calls)

How do these isolated rooms talk to each other without the Guard?

• They use Subsystem Calls. Think of this as a secure pneumatic tube.
• If the Network Driver needs to send data to the Scheduler, it puts the data in a tube.
• The tube automatically checks the ID of the sender and the receiver. It swaps the "ID badge" of the person using the tube.
• Crucially, the system wipes the slate clean (clears the registers) before and after the transfer. It's like putting on a fresh pair of gloves before handling evidence. This ensures no secret data leaks from one room to another.

5. The "Emergency Brake" (Real-Time Safety)

A common fear is: "If you break the OS into so many tiny pieces, won't it be too slow? What if a hacker freezes one room?"

• The Solution: The system uses Non-Maskable Interrupts (NMIs).
• Imagine a fire alarm that cannot be turned off. Even if a hacker tries to disable the alarm (by freezing a room), the hardware forces the system to listen to the alarm.
• This ensures that critical services (like stopping a heart monitor or blocking a network attack) always happen, even if the rest of the system is under attack.

The Trade-off: Security vs. Speed

The authors admit that this system is a bit "heavier" than a standard one.

• Analogy: It's like having a bank with 100 tiny, reinforced doors instead of one big main door. Every time you move between rooms, you have to go through a security check.
• The Result: It is slightly slower (overhead) and takes up more space (chip area).
• The Verdict: For critical infrastructure (like 5G towers, medical devices, or military systems), speed is less important than not getting hacked. The paper shows that while it's slower, it's still fast enough for real-world use, and the security gain is massive.

Summary

Skadi and Bredi are like building a fortress where:

1. No one is trusted (not the OS, not the drivers, not the hardware).
2. Access is granted only by tiny, unforgeable tokens.
3. If one part is hacked, the damage is contained to that tiny room.
4. Malicious devices (hacked trucks) are physically blocked from touching anything they aren't explicitly allowed to.

It's a shift from "Trust the Guard" to "Trust the Locks."

Technical Summary

Here is a detailed technical summary of the paper "Trust Nothing: RTOS Security without Run-Time Software TCB (Extended Version)" by Eric Ackermann and Sven Bugiel.

1. Problem Statement

Embedded devices face a triad of threat vectors: application software vulnerabilities, operating system kernel vulnerabilities, and malicious peripheral devices (specifically those with Direct Memory Access, or DMA).

• Current Limitations: Existing defenses typically address only two of these three vectors.
  • Traditional OS kernels with Memory Management Units (MMUs) protect against compromised applications and devices but require trusting the kernel to configure the MMU correctly.
  • Capability-based architectures (e.g., CHERI, RV-CURE) reduce the software Trusted Computing Base (TCB) but often exclude devices from the threat model, requiring trusted drivers or hardware changes to peripherals.
• The Gap: No existing architecture simultaneously provides security against untrusted application software, untrusted OS kernels, and untrusted DMA devices while maintaining soft real-time guarantees and eliminating the run-time software TCB.

2. Methodology

The authors propose a hardware-software co-design consisting of two main components:

1. Bredi (BreDi): A System-on-Chip (SoC) implementation of the Northcape capability architecture.
2. Skadi (SkaDi): A modified Zephyr Real-Time Operating System (RTOS) that utilizes Bredi to enforce strict compartmentalization.

A. The Northcape Architecture (Hardware)

Northcape moves capability enforcement from the CPU to the system bus level (Northbridge), allowing it to protect both software and hardware devices.

• Token-Based Capabilities: Instead of "fat pointers" (like CHERI), Northcape uses 64-bit tokens containing a Capability Number, a Nonce (for unforgeability), and an Offset.
• Resolution: When a memory access occurs, the Northbridge resolves the token against a Capability Metadata Table (CMT) in DRAM. It checks bounds, permissions, and nonces.
• Subsystems: The system is divided into mutually distrustful "subsystems." Access is granted only via explicit delegation of capability tokens.
• Key Hardware Features:
  • NTLB (Northcape TLB): A two-level cache hierarchy (L1 in CPU, L2 shared) to minimize the latency of recursive capability resolution, crucial for real-time performance.
  • Untrusted ISRs: The hardware supports register stacking (dual register sets for ISR vs. normal execution) and interrupt vectoring to ensure Interrupt Service Routines (ISRs) cannot leak state or hijack the interrupted subsystem.
  • Non-Maskable Interrupts (NMIs): Hardware support for NMIs ensures critical interrupt handlers cannot be disabled by malicious software, guaranteeing availability.
  • Subsystem-ID Restrictions: Capabilities can be bound to a specific subsystem ID. If a different subsystem guesses a valid token, access is denied because the active subsystem ID does not match.

B. The Skadi OS (Software)

Skadi is a Zephyr-based RTOS that eliminates the traditional kernel.

• No Run-Time TCB: The OS is decomposed into small, isolated subsystems (scheduler, allocator, drivers, network stack, etc.). The only trusted component is the Skadi Loader, which runs at boot, sets up the system, and then destroys itself (via a "trapdoor" subsystem), leaving no trusted software running at runtime.
• Compartmentalization: All subsystems communicate via subsystem calls. These calls atomically switch the active subsystem ID and program counter, ensuring mutual isolation.
• Untrusted Components: The scheduler, memory allocator, and all device drivers are untrusted. If the allocator is compromised, it cannot steal memory from other subsystems because it only holds capabilities to its own heap.
• Zero-Copy Networking: By delegating capabilities directly to DMA devices, Skadi enables zero-copy networking, improving performance and safety.

3. Key Contributions

1. First Full Implementation of Northcape: The paper presents Bredi, the first hardware implementation of the Northcape architecture on an FPGA (based on the cva6 RISC-V core), moving the concept from theory to practice.
2. Elimination of Run-Time Software TCB: Skadi achieves a state where no software component (kernel, drivers, scheduler) is trusted at runtime. Security relies entirely on the hardware capability enforcement and the one-time trusted loader.
3. Protection Against DMA Attacks: Unlike previous capability systems, Bredi's AXI MMU enforces capability checks on DMA devices, preventing them from accessing memory outside their delegated bounds without requiring hardware changes to the peripherals themselves.
4. Real-Time Guarantees: The system maintains soft real-time capabilities despite the overhead of capability checks. This is achieved through:
   • Optimized cache hierarchies (NTLB) to hide resolution latency.
   • Custom RISC-V instructions (e.g., calls for subsystem calls, register zeroing) to reduce cycle counts.
   • Hardware support for non-maskable interrupts to ensure availability.
5. Open Source Release: The authors plan to release both Skadi and Bredi under an OpenSource license.

4. Results

The prototype was evaluated on a Digilent Genesys 2 FPGA board.

• Security: The system successfully enforces confidentiality (C), integrity (I), and availability (A) against malicious applications, kernels, and devices. The "Trust Nothing" model is validated by the destruction of the loader and the isolation of all runtime components.
• Performance (Compute): In compute-bound benchmarks (Coremark, Stream), Skadi performs indistinguishably from an insecure Zephyr reference (within 0.13% difference) due to high L1 TLB hit rates.
• Performance (I/O/Networking):
  • Overhead: I/O-bound scenarios show higher overhead (approx. 3x–4x latency increase in ping/iperf) compared to Zephyr, primarily due to the high number of subsystem calls required for compartmentalization.
  • Practicality: Despite the overhead, absolute performance numbers remain practical for real-world embedded applications (e.g., network infrastructure).
  • Comparison to Linux: Skadi's performance is within the same order of magnitude as Linux on the same hardware, confirming its viability for general-purpose embedded tasks.
• Real-Time Capability:
  • Interrupt latency is increased (3x–7x overhead) compared to Zephyr but remains in the sub-millisecond range (~68µs average), suitable for soft real-time systems.
  • The system successfully handles preemption and non-maskable interrupts without stalling critical services.
• Area: The hardware implementation adds a manageable area overhead (approx. 31% increase in LUTs compared to the base cva6 core), with the L2 NTLB being the largest contributor.

5. Significance

This work represents a paradigm shift in embedded security:

• From "Trust the Kernel" to "Trust the Hardware": It demonstrates that it is possible to build a secure OS where the kernel itself is untrusted, relying instead on hardware-enforced capability isolation.
• Holistic Threat Model: It is one of the few systems to simultaneously address software vulnerabilities and hardware-level DMA attacks without requiring trusted drivers.
• Foundation for Future Systems: By proving that high security and soft real-time performance can coexist without a runtime TCB, Skadi and Bredi provide a blueprint for securing critical infrastructure (e.g., 5G base stations, industrial control systems) where supply chain attacks and firmware vulnerabilities are prevalent.
• Practicality: The use of standard Zephyr components and standard RISC-V toolchains (with minor macro extensions) suggests that this security model can be adopted without a complete rewrite of the embedded software ecosystem.