7 min to read

Milesan

Detecting Exploitable Microarchitectural Leakage via Differential Hardware-Software Taint Tracking.

TL;DR. MileSan is a sanitizer for CPUs that flags exploitable leakage by comparing what should be allowed by the ISA (architectural flows) with what the hardware actually allows (microarchitectural flows). If the “extra” flow can change instruction timing, MileSan catches it by watching for taint reaching the Program Counter (PC) in RTL simulation. Building on this, the authors introduce RandOS, a fuzzer that generates fully randomized “mini operating systems” spanning privilege levels and address spaces, finding new constant‑time violations and transient execution bugs across five RISC‑V CPUs, while rediscovering known ones 4.5× faster than prior work.

Why another sanitizer? The gap between architecture and microarchitecture

The ISA defines how information may flow architecturally (e.g., operands → results, tainted branch operand → control flow). But real CPUs add caches, TLBs, speculation, and other optimizations that introduce microarchitectural flows, many legitimate, some dangerous. Not every “extra” flow is a vulnerability: if it never becomes architecturally observable, it may be benign. The key observation behind MileSan:

Exploitable leakage is the architecturally observable difference between microarchitectural and architectural flows that surfaces through timing.

Formally, the paper names these differences Microarchitectural Information Overflows (MIOs) and detects them when they propagate taint to the PC. If a secret influences when an instruction completes, the program can measure that time, hence a covert channel exists.

Three kinds of overfitting in prior fuzzers (and how MileSan avoids them)

Research fuzzers often overfit to (1) where they look (hand-picked sources/sinks like “this buffer” → “that cache”), (2) what they look for (seed programs and templates tuned for specific bugs), and (3) how they look (detectors tied to a particular leakage mechanism). MileSan sidesteps all three:

• No microarchitecture assumptions. Sources = memory pages containing secrets. Sink = PC taint. If the timing changes, it’s exploitable.
• No program templates. The companion fuzzer RandOS creates randomized, multi-domain programs guided only by taint rules (details below).
• Unified detection. Timing-visible MIOs, whether constant-time violations or transient execution, are all caught by “taint-to-PC.”

Core idea and definitions

• AIF (Architectural Information Flow): Taint propagation permitted by the ISA (operands → results, tainted branch → architectural PC).
• MIF (Microarchitectural Information Flow): All flows in the implementation (inclusive of speculation, caches, queues, TLB, etc.).
• MIO: Architecturally observable subset of (MIF − AIF), what leaks beyond the ISA.
• Exploitability check: Does taint reach the PC? If yes, the leak is visible via execution time of some instruction, i.e., a covert channel exists.

MileSan computes AIF using software taint tracking for the running program and MIF using hardware taint tracking at RTL; their difference, if observable via PC, signals exploitable leakage.

Taint‑Aware In‑Situ Simulation (TAISS): enabling random programs without “taint explosions”

A practical hurdle: once pointers or the architectural PC become tainted, architectural taint explosion blinds everything. TAISS solves this during program generation by enforcing rules that allow rich arithmetic on secrets while preventing architectural spills:

• When generating code in a taint-source domain, TAISS forbids using tainted operands in control flow and pointer arithmetic.
• TAISS tracks AIF precisely while you append instructions, keeping architectural flows well‑formed and enabling complex, yet safe, computations on tainted data.
• Before crossing into a taint-sink domain, TAISS ensures all architecturally reachable state is untainted (registers, shared memory).

Result: we can explore deep microarchitectural behaviors without drowning in architectural taint.

Domains, layouts, and privileges: modeling real isolation

MileSan/RandOS model isolation as domains combining (a) virtual memory layout (which pages map where) and (b) privilege level (M/S/U). Programs traverse domains freely (system calls, exceptions, shared memory), while the sanitizer watches for PC taint:

• Source-domain PC taint: intra-domain leakage (e.g., constant‑time bugs, Spectre within the same privilege).
• Sink-domain PC taint: cross-domain leakage (e.g., Meltdown/MDS or cross-privilege Spectre).

RandOS: a “random OS” fuzzer built on MileSan

RandOS assembles programs as chains of Basic Blocks (BBs) across domains:

1. Boot BB (M-mode) initializes the machine.
2. Fuzzing BBs run in randomized privileges and layouts, with TAISS ensuring safe handling of taints in source domains and unconstrained randomness in sink domains.
3. A Terminating BB halts execution from any domain.

This “random OS” structure aggressively explores interactions (syscalls, faults, shared pages) without any hand-crafted templates.

From “there is a leak” to “here is the minimal PoC”: automatic triaging

Long, cross-domain programs can be hard to reason about. RandOS ships reduction passes that shrink a failing test to the essence:

• Control‑flow reduction: find the single leaker instruction (the covert channel) by chopping from the tail; then identify the first primer instruction by chopping from the head.
• Dead‑code reduction: remove architecturally unexecuted blocks; if leakage vanishes, binary‑search to the minimal transient gadget region.
• Taint reduction: binary‑search within tainted pages to the minimal set of secret bytes that must be present to trigger leakage.

Together, these yield short, comprehensible PoCs and precise root causes.

Evaluation highlights (5 RISC‑V CPUs)

Designs: Kronos, Rocket, CVA6, BOOM, OpenC910. Hardware DIFT via CellIFT or HybriDIFT at RTL.
What RandOS finds: all known bugs on CVA6/BOOM, plus 19 new constant‑time and transient vulnerabilities (including Spectre‑SLS and MDS variants).
Speed: RandOS exposes known BOOM bugs 3.8×–5.6× faster than SpecDoctor (mean 4.5×).
Constant‑time checks: Detected in one execution of the instruction with a tainted operand (e.g., div*/rem* families).
End‑to‑end exploit: On BOOM, a transient Meltdown‑style TLB channel leaks ~1 bit per ~2k cycles (~1 Mbps @ 2 GHz).

In short: one detector (PC taint) finds both constant‑time and transient classes, without microarchitecture‑specific heuristics.

Case studies (selected)

1) Transient Meltdown via the TLB on BOOM (CVE‑2025‑29343)

A branch is predicted taken; a transient gadget executes and loads privileged data, then performs a dependent load encoding a secret bit in the TLB. A later translation probes the TLB and leaks the bit via timing. Triaging trimmed the original long program down to a compact PoC that names the leaker and primer instructions and the exact memory bytes that must be tainted.

Exploit excerpt (simplified):

la   ra, secret
la   a2, buffer
# (flush TLB; create a transient window)
beqz t0, correct_target         # delayed branch resolves later
ld   a0, 0(ra)                  # transiently read privileged secret
andi a0, a0, 1                  # isolate bit
slli a0, a0, 12                 # encode into page offset
add  a2, a2, a0
ld   a2, 0(a2)                  # prime TLB with secret-bit index
correct_target:
# ... later, probe TLB to recover the bit

2) Straight‑Line Speculation & Spectre‑SLS on CVA6 (CVE‑2025‑29340)

With mstatus.SPP = S, an sret encounters straight‑line speculation; a transient window in S‑mode performs a secret‑dependent memory access that encodes the secret into the TLB, recoverable later in U‑mode due to insufficient flushing across privilege transitions.

3) MDS on CVA6 (CVE‑2025‑46004)

U‑mode faults on a privileged load; a stale value previously brought by S‑mode is transiently forwarded, enabling a dependent access that encodes the stale secret into the TLB, again detected as PC taint from a sink domain.

4) Constant‑time violations on OpenC910 (CVE‑2025‑46005)

Eight arithmetic instructions (e.g., div[u][w], rem[u][w]) show data‑dependent latency; a single execution with tainted operands suffices to taint the PC.

What MileSan/RandOS buy you in practice

• One unifying oracle: timing-visible leakage ⇢ PC taint.
• Generalization instead of guesswork: no hand-picked source/sink internals, no templated programs.
• Faster discovery and clearer PoCs: automatic reduction to leaker, primer(s), and bytes that matter.
• Broad coverage: intra-domain (constant‑time, Spectre‑V1/V2/RSB/V4) and cross‑domain (Meltdown, MDS, cross‑privilege Spectre).

Frequently asked questions

Q: Why does “PC taint” imply exploitability?
Because if a secret changes when an instruction completes, a program can measure the timing, creating a covert channel. MileSan flags exactly those cases.

Q: Doesn’t software taint explode anyway?
TAISS prevents architectural taint from contaminating control flow or pointers in source domains, while allowing rich computations on secrets. Before entering sink domains, it sanitizes architecturally reachable state.

Q: How is this different from fuzzers that monitor specific buffers?
Those may report flows that never reach software. MileSan only reports architecturally observable leakage by construction.

Artifact

Code (MileSan + RandOS) and documentation are available at https://comsec.ethz.ch/milesan.