Making Software Both Memory-Safe and Leak-Proof: Introducing BLACKOUT

Two major challenges stand in the way of protecting critical software like cryptographic libraries that secure websites, messaging apps, and smartphone communications: memory-safety and side-channel leakage.

The memory-safety hardening challenge

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.

The side-channel leakage problem

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.

Why hardware matters

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.

Introducing BLACKOUT

 

Working with experts from Ericsson Research, we have designed BLACKOUT: a hardware-software co-design that extends CHERI to tackle both problems—memory-safety and side-channel leakage—at the same time.

We designed BLACKOUT to build on CHERI’s memory-safety features, which replace all memory references in C and C++ programs with capabilities—secure objects that include information about the memory they can access. This prevents buffer overflows, stops capabilities from being mistaken for regular data, and—together with a CHERI-aware memory allocator—blocks access to freed and reused memory.

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.

Writing software for BLACKOUT

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.

BLACKOUT hardware

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

• almost no overhead compared to baseline CHERI for constant-time code (just 1.5%) and 
• only a moderate overhead compared to completely unprotected processors (around 23%).

BLACKOUT is the first unified approach to achieve both memory-safety and side-channel confidentiality  with minimal performance, which can pave the way to practical deployment.

Try It Yourself

The source code for BLACKOUT—both hardware and software—is available here: https://github.com/blindedcapabilities

Takeaways

• Memory-safety stops attackers from breaking software through memory bugs.  
• Side-channel resistance stops them from observing secrets indirectly.  
• BLACKOUT combines both, in hardware and software, with minimal performance costs.

This moves us a big step closer to building truly safe cryptographic systems for the real world.

Learn more

• For more information regarding BLACKOUT, read our paper: Data-Oblivious Computation with Blinded Capabilities to appear in the ACM Conference on Computer and Communications Security (CCS ’25) (also available on arXiv).
• For more information on data-oblivious execution, take a look at our other papers.