💻 computer science

obliv-clang: Real-World Oblivious Programming in C++

The paper introduces obliv-clang, a compilation-time checking tool that formally verifies the obliviousness of C++ programs with complex features like nested pointers to prevent side-channel leaks while maintaining high performance and compatibility with industry codebases.

Original authors: Yunqian Luo, Mingyu Gao

Published 2026-06-16

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Yunqian Luo, Mingyu Gao

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a master chef preparing a secret recipe in a high-security kitchen. The goal isn't just to keep the ingredients hidden; it's to ensure that no one watching your movements can figure out what you are cooking.

If you grab a pinch of salt only when the recipe calls for it, or if you stop chopping when you reach a specific step, a spy watching from the window could guess your recipe just by timing your actions or counting your knife strokes. This is what computer scientists call a "side-channel attack."

The paper introduces obliv-clang, a new tool designed to stop this kind of spying. Here is how it works, explained simply:

1. The Problem: The "Leaky" Kitchen

In the digital world, even if your data is locked in a "Trusted Execution Environment" (a secure vault), hackers can still peek at how the computer behaves. They look at:

Timing: How long a calculation takes.
Access Patterns: Which memory slots the computer touches.

If a program behaves differently based on secret data (like a password), the hacker can deduce the secret just by watching the "dance" of the computer.

2. The Solution: The "Oblivious" Chef

To fix this, programmers need to write code that is "oblivious." This means the program must act exactly the same way, regardless of whether the secret data is a "1" or a "0." It's like a chef who chops vegetables for exactly 10 seconds every time, whether they are actually chopping onions or just pretending to, so the spy can't tell what's happening.

Writing this kind of code by hand is incredibly difficult and error-prone. One tiny mistake (like using an if statement that depends on a secret) ruins the whole security.

3. Enter obliv-clang: The Strict Inspector

The authors built obliv-clang, which acts like a super-strict inspector for C++ code (the language used by most major software companies).

It speaks the language of the pros: Unlike previous tools that forced programmers to learn a weird, new, made-up language, obliv-clang works directly with C++. It understands complex things like pointers (variables that point to other variables), classes, and templates. It's like having an inspector who knows exactly how a professional kitchen works, rather than one who only understands a simplified toy kitchen.
The "O-Level" System: The tool uses a concept called Oblivious Levels (olevels). Think of this as a security clearance badge.
- A public variable has a low clearance.
- A secret variable has a high clearance.
- The tool checks every single line of code to ensure you never accidentally hand a high-clearance secret to a low-clearance person. It even tracks "pointers to pointers" (like a map to a map to a secret) to make sure the secret doesn't leak through a chain of references.
The "Unsafe" Zone: Sometimes, you need to do something risky (like debugging or using a third-party library). The tool allows you to mark these specific areas as "Unsafe," effectively saying, "I, the human programmer, promise to be careful here." This is similar to how a driver might take off their seatbelt only in a parking lot, but the tool forces you to explicitly acknowledge that risk.

4. Why It's Better Than the Old Ways

Previous tools were like trying to build a house with a different set of blueprints than the rest of the neighborhood. They were hard to use, slow, or didn't fit with existing software.

Compatibility: obliv-clang fits right into the existing tools (Clang and LLVM) that engineers already use.
Speed: Because it doesn't force the computer to do unnecessary "dummy" work to hide its tracks, the resulting programs are much faster. The paper claims programs written with this tool run 27.8% faster than those made with one competitor and 66.9% faster than another.
Safety: It doesn't just guess; it mathematically proves that if the code passes the check, it is safe from these specific types of timing attacks.

5. The Result

The authors tested obliv-clang on real-world algorithms (like encryption and data search). They found:

It adds very little time to the process of compiling the code (less than 18% extra time).
It catches real security flaws that humans missed (like a specific vulnerability in OpenSSL that allowed hackers to steal keys).
It produces software that is both secure and fast.

In summary: obliv-clang is a tool that helps programmers write "invisible" code in C++. It ensures that the computer's behavior gives away no clues about secret data, all while keeping the software fast and compatible with the massive amount of existing code in the world.

Technical Summary: obliv-clang: Real-World Oblivious Programming in C++

Problem Statement

Side-channel vulnerabilities, specifically those exploiting timing and access patterns (e.g., via shared caches, page tables, or branch predictors), remain a critical threat to confidential data processing even within Trusted Execution Environments (TEEs). While hardware isolation protects data at the architecture level, execution traces can still leak secrets if program behavior depends on sensitive values.

Existing solutions for oblivious programming (programming where execution traces are independent of secret data) face significant limitations:

Domain-Specific Languages (DSLs): Tools like Jasmin and FaCT require rewriting code in new languages, creating high integration costs and lacking standard toolchain support (debugging, libraries).
Separate Modeling: Approaches that check obliviousness via separate models struggle with consistency between the model and the actual implementation.
Compiler Transformations: Automatic transformations in existing compilers often rely on conservative assumptions, leading to significant performance degradation or failing to handle complex code patterns.
Language Complexity: C++ features such as arbitrarily nested pointers, references, templates, and object-oriented polymorphism are difficult to model for obliviousness without a rigorous, sound framework.

Methodology

The authors present obliv-clang, a compiler plugin for the Clang/LLVM infrastructure that performs static, compile-time checking of obliviousness directly on C++ source code. The system is designed to integrate seamlessly with existing industry-level C++ codebases.

Core Design: Obliviousness Levels (olevels)

To handle C++'s complex memory model, the authors introduce obliviousness levels (olevels). An olevel is a binary string representing the secrecy status of an expression at different levels of indirection (dereferencing).

Representation: The $i$ -th digit of the olevel string indicates the obliviousness after dereferencing $i$ times. An expression is considered "oblivious" if its olevel ends in 1.
Dataflow Rules: The system enforces a set of rules to prevent secret data from flowing into public domains or influencing control flow:
- Arithmetic & Logic: Any expression depending on an oblivious object is itself oblivious.
- Casting & Assignment: Assignments are restricted based on olevel compatibility. Specifically, assigning an oblivious value to a non-oblivious target is forbidden unless specific conditions regarding "constantness" (inherited from C++ const semantics) are met to prevent aliasing attacks (e.g., assigning a public pointer to a secret pointer's target).
- Control Flow: Conditional statements (if, while, switch) cannot depend on oblivious expressions.
- Dereference: Dereferencing an oblivious pointer is forbidden, as it would reveal memory access patterns dependent on the secret address.

Handling C++ Features

obliv-clang extends these rules to support:

Pointers and References: Using olevels to track secrecy through nested pointers (e.g., char***).
Function Calls: Parameters and return values are annotated with olevels. The tool checks consistency between call sites and function definitions, even across translation units.
Classes and Polymorphism: Class members inherit olevels from their instances (denoted by x in the olevel string). Virtual method calls on oblivious polymorphic pointers are forbidden to prevent leaking vtable information.
Templates: Each template instantiation is checked individually, allowing different olevel requirements for different instantiations.
Unsafe Blocks: Inspired by Rust's unsafe keyword, the obliv_unsafe attribute allows developers to bypass checks for specific blocks (e.g., interacting with external libraries or implementing complex cryptographic primitives), placing the burden of correctness on the programmer.

Soundness and Backend Safety

The authors provide a formal proof of soundness (Theorems 1, 3, and 4), demonstrating that if a program passes the static checks, it satisfies secrecy and dataflow properties, preventing attackers from distinguishing execution traces based on secrets.

To ensure the backend (LLVM optimizer) does not break these guarantees, the tool:

Disables Specific Optimizations: It manually suppresses optimization passes known to reorganize control flow or memory access patterns (e.g., loop unrolling, vectorization, and cmov conversion).
Double-Check Mechanism: It optionally employs an external tool (pitchfork) to verify the generated assembly code. If verification fails, the compiler recompiles the specific unit with optimizations disabled (optnone).

Key Contributions

Implementation: A functional compiler plugin (obliv-clang) that integrates with the mature Clang/LLVM ecosystem, supporting the full C++ language.
Formal Rules: A comprehensive set of obliviousness check rules that handle complex C++ features, including arbitrarily nested pointers, templates, and object-oriented constructs.
Formal Proof: A soundness proof establishing that programs passing the checks are safe against timing and access-pattern side channels.
Evaluation: Empirical evidence demonstrating expressiveness through non-trivial case studies and performance advantages over existing tools.

Results and Evaluation

The authors evaluated obliv-clang using several benchmarks and compared it against state-of-the-art tools (Jasmin and FaCT).

Expressiveness: The tool successfully compiled complex oblivious algorithms, including:
- PathORAM: A non-recursive implementation (251 lines) handling binary tree position maps.
- Oblivious BFS: A graph traversal algorithm (158 lines).
- Vulnerability Detection: The tool automatically caught a known timing vulnerability in OpenSSL's ECDSA implementation (CVE-2024-13176) where secret data flowed into a non-oblivious function.
- Annotation Overhead: Only 8% to 17% of the codebase required [[obliv]] annotations, primarily for variable declarations and function signatures.
Compilation Overhead: The static check adds minimal overhead, increasing compilation time by less than 11% (without double-check) and 18% (with double-check).
Runtime Performance:
- Optimization Suppression: Disabling specific LLVM passes caused negligible slowdown for most benchmarks (e.g., <2% for Tiny JPEG, Oblivious BFS) but up to 29.5% for PathORAM, which relies heavily on loop optimizations.
- Comparison: On average, programs compiled with obliv-clang ran 27.8% faster than Jasmin and 66.9% faster than FaCT. The authors attribute this to leveraging the highly optimized LLVM backend, whereas DSLs often require custom code generation or less efficient transformations.

Significance and Claims

The paper claims that obliv-clang represents a significant step toward practical, real-world oblivious programming. By supporting standard C++ rather than requiring a DSL, it lowers the barrier to entry for developers and allows for the integration of oblivious security into existing, complex codebases with minimal porting effort.

The authors emphasize that their approach balances usability (familiar language, low annotation burden) with security (formal soundness proofs, backend verification). While they acknowledge that disabling some compiler optimizations incurs a performance cost, they argue this is an acceptable trade-off for security and that their tool generally outperforms previous solutions by avoiding the inefficiencies of custom DSL compilers. The work demonstrates that rigorous obliviousness checking is feasible within the constraints of a modern, feature-rich language like C++.