Granite: A Modular Methodology for Foundational Verification of Hardware-Software Leakage Contracts. In this 2026 work, Stella Lau, Andres Erbsen and Adam Chlipala ask whether a processor implementation can be proved functionally correct while also revealing no timing information beyond an explicit hardware-software contract. The work reaches RTL. It covers a pipelined processor with speculation, precise interrupts and input and output. By the end, you should understand how Granite handles variable but public behavior, how its modular proofs connect software policy to cycle-level observations, and where that guarantee stops.

Constant-time programming aims to keep execution time independent of secrets. That promise depends on the hardware honoring the same boundary. The ISA, which stands for instruction set architecture, defines the contract between software and the processor. A leakage-aware version also declares which events may affect observable timing. Granite's example policy permits dependencies such as memory addresses, branch decisions and arguments to variable-latency instructions. Everything else should remain hidden. The resulting nonleakage property says that cycle-level signals, including ready and valid behavior, reveal nothing beyond those declared events. Proving this at RTL would rule out additional cycle-level timing channels for programs whose permitted observations are themselves independent of secrets.

The difficulty is nondeterminism: behavior that is allowed to vary without being random or secret-driven. A specification may leave instruction latency, interrupt placement or component response time open. Real hardware also experiences external inputs and variable memory timing. Fixing every detail could reject secure implementations, while leaving choices completely unconstrained could let those choices encode secrets. Granite therefore investigates whether these variations can be represented as deterministic decisions based only on public information, while retaining functional correctness and modular component proofs.

Granite is formalized in Rocq. The proof requires the implementation and a family of cycle-accurate specification machines to produce the same observable sequence; Granite calls this relationship trace equivalence. A deterministic mechanism resolves choices such as when to emit an input or output request or take an interrupt. This public driver can inspect public inputs, the program and events that the contract explicitly allows to leak, but it cannot base its decisions on other secrets. Another mechanism converts those permitted events into the timing an adversary observes; Granite calls it a leakage transformer. To connect the architectural specification to RTL, the proof also runs a version of the implementation that makes decisions using only information permitted by the leakage trace. This is the public shadow. Components receive their own correctness and leakage specifications, and the checked component proofs compose into the processor-level result.

Lau, Erbsen and Chlipala built a machine-checked correctness and confidentiality proof for synthesizable RTL implementing a pipelined processor. The design includes branch prediction and support for exceptions, interrupts and memory-mapped input and output. They also proved a static analysis for constant-time software: an accepted program running on a processor satisfying the specification does not leak secrets at RTL under the modeled policy. Their Salsa20 case connects compiled software to that hardware result. The machine-checked proof removes the RTL implementation and its intermediate proof machinery from the trusted computing base, so those parts do not simply have to be assumed correct. A separately verified 3-stage multicycle processor required a substantially different top-level proof but no meaningful specification changes.

A zero-skipping multiplier makes the mechanism concrete. Its response timing may depend on whether either operand is zero, because the contract explicitly permits that fact to leak, but not on the operands' other data. The timing must therefore be a fixed function of whether either operand is zero. Interrupts require careful sequencing: the public driver cannot choose an outcome with observable effects until the implementation has resolved that choice. A bad driver does not weaken the theorem; it prevents the proof from being completed. The researchers also handle speculative loads when both the speculative address and the decision to issue the request are secret-independent. Together, these cases test whether the same proof structure can accommodate variable component latency, precise interrupts and speculative behavior without silently granting them access to secrets.

The guarantee is limited in scope. First, its observation model covers cycle-by-cycle timing, not timing variations within a cycle, power consumption or attacks requiring physical access. Second, the evaluated processor design uses a minimal RISC subset, a single hardware thread and read-only instruction memory. Third, the proof scope does not connect to the compiler-verification research that influenced the architectural specification. One speculative-load variant also deliberately assumes no functional correctness for memory, so it should not be read as verification of the memory subsystem. More generally, the result applies when software keeps the contract's permitted observations independent of secrets; it does not demonstrate that arbitrary software or existing processors are secure.

Begin by stating exactly which branch decisions, addresses or variable-latency inputs may affect timing. Interrupt placement, memory progress and similar choices would then need to be proved dependent only on public information. Component teams could verify their blocks against smaller leakage-aware specifications and compose those results upward, instead of treating the entire processor as one proof problem. For processor security architects and formal-verification teams, this makes the declassification boundary auditable. My operational interpretation is that Granite is a design-and-assurance method, not a runtime detector or a drop-in mitigation.

Granite's evidence supports a modular, machine-checked connection from a constant-time software policy through an instruction-set leakage contract to cycle-level processor behavior. Chip security teams, hardware verification engineers and cryptographic software assurance teams are the likely audience. They can use the methodology as a blueprint for specifying allowed timing dependencies and proving that implementation choices stay within them. They should not infer that any constant-time program is safe on any processor, or that the proof covers power, sub-cycle timing, physical attacks or richer multicore systems. The demonstrated guarantee remains specific to the verified designs, software conditions and observation model.