Memory-safety means making sure a software application only reads from and writes to memory it’s supposed to. Without it, applications can inadvertently contain memory-safety vulnerabilities, flaws in software that can allow attackers to hijack programs, steal secrets, or crash systems. Unfortunately, most of today’s foundational software is written in C and C++, languages that are not memory-safe.

This has been a problem for decades. Regulators and security agencies such as the US CISA and the UK NCSC are now urging the move to memory-safe languages like Rust, or to new hardware that enforces memory safety, like CHERI (Capability Hardware Enhanced RISC Instructions).

Rust is promising, but rewriting the billions of lines of C and C++ code in existence is not realistic. That’s why memory-safe hardware like CHERI, which can make old code safer without rewriting it, is so attractive.

Even if memory is safe, secrets can still “leak” through side-channels.

A side-channel is an indirect way an attacker can spy on a program—for example, by measuring how long it takes to run, or watching how it uses the CPU cache. These tiny clues can reveal sensitive information like encryption keys which must remain confidential for encrypted data to remain private.

Developers try to prevent this by writing constant-time code, which takes exactly the same amount of time to run no matter what the secret data is. That way, an attacker can’t learn any new information merely by timing it.

But constant-time programming is hard. A single misplaced if statement, or an optimization by the compiler, can reintroduce leaks. Unlike memory bugs, which usually cause crashes and get noticed, side-channel flaws often fail silently. You might not know anything is wrong until after an attacker steals data.

Rust makes things trickier: its high-level abstractions are nice for developers, but they make it even harder to guarantee true constant-time behavior once the compiler generates machine code.

Side-channel resistance isn’t just about software. It’s about the whole system: hardware and software together.

CHERI hardware prevents memory-safety issues but doesn’t directly fix side-channel leaks. Some research has hardened CHERI against speculative-execution attacks (think Spectre or Meltdown), but those don’t cover all the ways secrets can leak.

Other approaches exist, like adding special “tag bits” to memory to mark which data is sensitive, but those come with heavy performance costs and extra memory usage.

How it works:

BLACKOUT adds special blinded capabilities to CHERI. When data is marked secret, the CPU always addresses it using a blinded capability. Inside the CPU, a special blindedness bit is used to track secret data loaded via a blinded capability. Any result of calculation based on secret data is automatically marked as secret too, and the CPU ensures that if secret data it is handling is written to memory, it must happen also via a blinded capability.

Crucially, if an application tries to use secret data in a way that risks leaking it—say, by using it to control program flow or memory addresses—the CPU halts the operation. This cuts off entire classes of side-channel leaks at the root.

In short: if secret data is used incorrectly, the program fails fast instead of silently leaking.

The BLACKOUT processor blocks any program that could leak secrets, but writing constant-time code that runs correctly on it remains challenging. To ease this burden, we built a BLACKOUT programming model for CHERI C with Clang/LLVM support. Developers can mark secret data with a “blinded” annotation, and the hardware enforces security by faulting if that data is ever misused.

Domain experts can annotate further uses of secret data, while the compiler propagates these annotations where possible. If propagation is incomplete, developers can rely on hardware faults to reveal missing annotations until the program runs cleanly. The compiler can also warn the developer of clear leaks already at compile time.

This makes writing constant-time code much more reliable—and far less error-prone—than current approaches.

Developers can also use other constant-timeness verification tools together with BLACKOUT. But achieving constant-time software via static analysis or formal methods alone each face their own challenges. Capturing microarchitectural subtleties of real-world hardware in formal models (and keeping the models up-to-date as hardware evolves) is difficult. Static analyses may not be sound and can lead to over- or under-tracking. BLACKOUT closes this gap because it ensures constant-time implementations.

We built BLACKOUT on a CHERI-RISC-V processor running on an FPGA, integrated it with the CheriBSD operating system, and ran industry-standard benchmarks.

The results show that BLACKOUT imposes