Hardware-Faithful Verification

• Hardware-Faithful Verification is a discipline that validates system properties on the actual hardware artifact, preserving bit-width, timing, and operational semantics.
• It spans multiple domains—from PLC software and remote attestation to binary-level proofs—ensuring that abstract models accurately reflect physical implementations.
• By embedding hardware-specific details into the verification process, it reduces false alarms and enhances trust in the system’s operational security.

Hardware-faithful verification denotes verification that is aligned with the deployed artifact rather than an abstract surrogate. In recent work, it means verifying “exactly the program that will execute on a specific microcontroller board” for IEC 61131-3 PLC software, validating attestation evidence “exactly according to the hardware vendor’s scheme,” keeping an executable SysML model “directly inside the verification loop,” proving CHERI security objectives “directly on the timing-accurate RTL implementation,” and establishing properties of RISC-V binaries against a formal ISA semantics “that is intended to match real hardware” (Dantas et al., 9 Jul 2026, Sinaki et al., 13 Feb 2026, Lewis et al., 11 May 2026, Antón et al., 2024, Palmskog et al., 18 Mar 2025). This suggests a shared concern with the gap between an abstract model and the concrete hardware artifact, but the literature uses the term at several layers: board deployment, attestation, MBSE hardware interaction, RTL security, and binary analysis.

1. Definitions and scope

Recent papers use closely related but domain-specific definitions of hardware-faithful verification.

Context	Hardware-faithful verification means	Representative paper
Open-hardware PLCs	“verifying exactly the program that will execute on a specific microcontroller board”	(Dantas et al., 9 Jul 2026)
Remote attestation	evidence is validated “exactly according to the hardware vendor’s scheme”	(Sinaki et al., 13 Feb 2026)
MBSE / SysML	verifying the physical implementation “directly against the authoritative system model”	(Lewis et al., 11 May 2026)
Sequential RTL	proving the implementation is “functionally and bit-accurate” with timing and interface semantics	(Olmos et al., 2024)
Binary verification	proving properties of “the concrete machine code that the hardware executes”	(Palmskog et al., 18 Mar 2025)
CHERI security	proving security objectives “directly on the timing-accurate RTL implementation”	(Antón et al., 2024)

These formulations are not identical. Some are centered on machine integers and I/O domains, some on attestation semantics, some on executable models, and some on microarchitectural confidentiality and integrity. The common pattern is that fidelity is treated as a property of the verification model itself: word widths, peripheral resolutions, memory layout, timing, privilege rules, and architectural interfaces are part of what must be preserved.

The literature also distinguishes hardware-faithful verification from several neighboring practices. It is not merely bounded testing on a prototype, not merely proving properties on an ISA or source-language abstraction, and not merely preserving syntax across toolchain translations. Where the term is used most strongly, the claim is that the proof or counterexample ranges over the same semantics that determine deployed behavior.

2. Deployment-faithful verification for open-hardware PLCs

In open-hardware PLC verification, the motivating problem is a “deployment gap” between the abstract scan-cycle model used by traditional IEC 61131-3 verifiers and the deployed model on a board artifact. PLC verifiers such as ESBMC-PLC and PLCverif traditionally analyze an abstract scan-cycle model where integers are idealized and inputs are unconstrained, whereas AVR-class Arduinos execute C code with 16-bit int and read sensors through a 10-bit ADC with values in $[0,1023]$ (Dantas et al., 9 Jul 2026).

ESBMC-Arduino formalizes the deployed model as $M_{\mathrm{dev}}(P,H)$, where the Hardware Abstraction Layer descriptor is

$H=\langle W,R,P,\mu\rangle,$

with $W$ the machine word width, $R$ the ADC resolution, $P$ the PWM resolution, and $\mu$ mapping IEC 61131-3 direct-address classes to roles and domains. The faithful lowering modifies only the hardware boundary. Arithmetic is evaluated over $W$-bit two’s-complement bit-vectors:

$$x_W=x \bmod 2^W,\qquad (x \oplus y)=(x+y)\bmod 2^W,\qquad (x \otimes y)=(x\cdot y)\bmod 2^W,$$

and inputs are constrained to hardware-realizable domains derived from direct addresses and the board descriptor:

$$\texttt{assume}(0 \le r \le 2^R-1),\qquad \texttt{assume}(b \in \{0,1\}).$$

The central empirical result is that naïve width-aware overflow checking without an input model is unsound in practice. Across a 123-program third-party corpus, checking 16-bit overflow without a hardware input model produced a 44% false-alarm rate, $M_{\mathrm{dev}}(P,H)$0, and found zero genuine defects; all 54 alarms were triggered by inputs outside any ADC domain, such as $M_{\mathrm{dev}}(P,H)$1. With the HAL annotator, all 54 false alarms were eliminated while preserving every robustness proof; 32 safe verdicts were preserved and the remaining 91 programs were Unknown because of k-induction limits over function-block internal state rather than input modelling (Dantas et al., 9 Jul 2026).

The paper’s example makes the safety consequence concrete. A ladder rung reads a 10-bit level sensor, computes

$M_{\mathrm{dev}}(P,H)$2

and raises an alarm when percent ≥ 80. On a 16-bit AVR target, $M_{\mathrm{dev}}(P,H)$3 overflows for high readings. At $M_{\mathrm{dev}}(P,H)$4, the wrapped product is 23,541, so percent = 23 and the high-level alarm remains false despite the sensor being above 80%. The same program is safe on a 32-bit target with the same input bounds. This is the characteristic “missed defect” that the abstract model can miss, complementing the “phantom alarm” introduced by unconstrained inputs.

The broader significance is explicit in the paper’s statement that the gap lies “where computation meets the physical process.” Hardware-faithful PLC verification therefore couples finite-width machine arithmetic with bounded, hardware-realizable sensor inputs, so that proofs are sound with respect to an actual board and counterexamples are physically realizable.

3. Bit-accurate equivalence, binary semantics, and representation-preserving translation

A second line of work treats hardware faithfulness as preservation of bit-accuracy, latency, and interface semantics across representations. In “Verifying Non-friendly Formal Verification Designs: Can We Start Earlier?”, MetaHLEC first verifies an untimed C/C++ algorithm against generated assertions, then proves high-level equivalence between that algorithm and a sequential RTL design using metamodel parameters for Size, Sign, Delay, Condition, Stalling, clock, and reset (Olmos et al., 2024). The intended equivalence is stated as

$M_{\mathrm{dev}}(P,H)$5

so hardware faithfulness is not only bit-accuracy but also timing alignment and interface validity. The paper reports conclusive algorithm-level proofs in seconds, including 10 FPU-related assertions in 4.9 s, a SIMD multiplier algorithm-level check in 1.1 s, and a quadratic fractional polynomial in 0.03 s.

CREST pushes the same concern into industrial datapath verification by adapting CBMC so that ANSI-C reference models are translated into solver-friendly Verilog while preserving bit-level semantics of casts, integer arithmetic, floating-point conversions, unions, structs, pointer aliasing, and memory layout (Tiemeyer et al., 2019). Sequential RTL is then related to the combinational C reference by latency-aware properties of the form

$M_{\mathrm{dev}}(P,H)$6

This places timing and handshake assumptions in the verification environment rather than pretending that a sequential implementation is equivalent to a zero-latency model without alignment.

Btor2MLIR treats hardware faithfulness as preservation of the bit-precise, synchronous semantics already encoded in Btor2. It uses Btor2Tools to parse Btor2, maps operators one-to-one into a custom MLIR Btor Dialect, models init and next with explicit control flow, and lowers to LLVM dialect through pattern-based rewrites such as lowering slice to logical shift-right plus truncation (Tafese et al., 2023). Round-trip validation on HWMCC20 shows stable safe/unsafe outcomes, which supports the claim that parsing, translation, and lowering need not introduce semantic drift.

At the binary level, HolBA makes the same move with a smaller trusted computing base. Contracts are stated over the L3 formal RISC-V ISA model, proved automatically by forward symbolic execution over BIR, and transferred back to the ISA by a proof-producing lifting theorem (Palmskog et al., 18 Mar 2025). The paper frames the payoff directly: binary-level proofs avoid trusting compilers, source-language semantics, and hand-crafted assembly embedded in source code. In this setting, hardware-faithful verification means proving properties of the machine code that the hardware executes, up to the fidelity of the formal ISA model itself.

Taken together, these works show that “hardware-faithful” does not denote a single proof engine. It denotes a discipline of preserving exact widths, signedness, memory layout, cycle latency, and transition semantics across the boundaries between algorithmic descriptions, intermediate representations, RTL, and binaries.

4. Hardware/software co-verification and attestation semantics

In trusted computing and remote attestation, hardware-faithful verification is tied to platform-specific cryptographic and access-control semantics. TrustMee introduces “self-verifying remote attestation evidence”: each attestation bundle carries its own platform-specific verifier as a WebAssembly component together with the raw evidence, and the verifier host first authenticates this embedded logic and then executes it to validate the evidence and produce normalized claims (Sinaki et al., 13 Feb 2026). Evidence verification is reduced to checking

$M_{\mathrm{dev}}(P,H)$7

for the Verification Component $M_{\mathrm{dev}}(P,H)$8, after which platform-specific parsing and crypto remain inside the WASM component. For AMD SEV-SNP and Intel TDX, this includes certificate-chain validation, signature verification, measurement decoding, and TCB checks. The paper’s hardware-faithfulness argument is that the host does not reinterpret platform-specific data, so there is no semantic drift caused by host-side reimplementations.

VRASED makes the same issue concrete at the level of a real MCU. It models and verifies hardware components as finite-state machines over OpenMSP430 signals such as $M_{\mathrm{dev}}(P,H)$9, $H=\langle W,R,P,\mu\rangle,$0, $H=\langle W,R,P,\mu\rangle,$1, $H=\langle W,R,P,\mu\rangle,$2, $H=\langle W,R,P,\mu\rangle,$3, $H=\langle W,R,P,\mu\rangle,$4, irq, and reset, and specifies remote-attestation security in LTL (Nunes et al., 2018). Representative properties include key access control,

$H=\langle W,R,P,\mu\rangle,$5

atomicity and controlled invocation,

$H=\langle W,R,P,\mu\rangle,$6

DMA protection,

$H=\langle W,R,P,\mu\rangle,$7

and secure reset,

$H=\langle W,R,P,\mu\rangle,$8

The attestation software then uses HACL* verified HMAC-SHA256, and the end-to-end soundness statement binds the final attestation result to the actual memory region and nonce. Here hardware faithfulness is explicitly the opposite of proving remote attestation on an abstract CPU model.

FVCARE generalizes the same pattern for resilient embedded SoCs by splitting the problem into two modules: hardware verification of initial system settings, registers, cryptographic engines, and access-control policies with bit-precise models in NuSMV, and source-level verification of system specification, security properties, and functional correctness using Frama-C Value, WP, and Aorai (Dave et al., 2023). Hardware-verified assumptions such as immutable ROM or PMP policy become contracts in software proofs. The approach is therefore not a collapse of HW/SW reasoning into one abstraction level, but an explicit connection between a bit-precise hardware layer and a source-level abstraction layer.

These attestation and co-verification papers treat hardware faithfulness as a trust-boundary problem. Verification is faithful only when the hardware-specific semantics that determine appraisal, memory isolation, interrupt handling, DMA behavior, and key access are preserved in the proof model rather than delegated to informal assumptions.

5. Direct verification on RTL implementations and physical hardware

A more radical form of hardware-faithful verification dispenses with ISA compliance as the primary objective and proves global security objectives directly on RTL. VeriCHERI adopts this position for CHERI. Instead of checking compliance with a golden ISA model, it checks confidentiality and integrity on the timing-accurate RTL implementation using as few as four unbounded properties: 1-safety-integrity, a monotonicity invariant, 1-safety-confidentiality, and UPEC-CHERI (Antón et al., 2024). The reduced 1-safety properties are

$H=\langle W,R,P,\mu\rangle,$9

and

$W$0

UPEC-CHERI then refines confidentiality to architectural noninterference and detects Meltdown-style timing leakage. The case study on CHERIoT Ibex found a capability store bug that crossed bounds on the second auto-incremented write and a Meltdown-style vulnerability in which an illegal instruction fetch delayed a pipeline flush depending on two bits of fetched data.

A different but related direction appears in SHIA, where hardware-faithful verification in MBSE/SysML means verifying the physical implementation directly against the authoritative system model without transformation chains, co-simulation platforms, or broker-mediated plugins (Lewis et al., 11 May 2026). The executable SysML model remains inside the verification loop through a SysML-side server in IBM Rhapsody and a hardware-side server on a Raspberry Pi. The proof-of-concept uses minimal fixed-length 2-character ASCII messages over serial UART, with commands such as "11" for input pin 1 HIGH and "10" for input pin 1 LOW. Verification is staged through Model Only Mode, prototype isolated test, Model Replacement Mode, and integrated verification. For the logic-gate case study, Karnaugh map comparison between SysML-generated and hardware-generated outputs showed zero discrepancy, with

$W$1

across all five outputs and 32 input combinations.

These two works operate at very different abstraction levels, but both reject the idea that faithfulness is satisfied by proving an abstract model and then assuming the implementation conforms. One proves confidentiality and integrity directly on the RTL microarchitecture; the other keeps the executable system model in direct communication with physical hardware. In both cases, the implementation artifact itself remains in the verification loop.

6. Recurrent themes, misconceptions, and limits

Several misconceptions recur across the literature. One is that adding finite-width arithmetic to an abstract model is enough. ESBMC-Arduino shows that turning on 16-bit overflow checks without a hardware input model yields “phantom alarms” because the solver explores sensor values that no ADC can produce; the 44% false-alarm rate on 123 programs is the paper’s direct demonstration of this point (Dantas et al., 9 Jul 2026). Another is that ISA-level or source-level correctness exhausts security assurance. VeriCHERI argues that ISA-level verification cannot cover non-functional behaviors such as timing differences introduced by pipelines, caches, or exception machinery, and its CHERIoT Ibex case study found a Meltdown-style vulnerability precisely at that layer (Antón et al., 2024).

A second recurrent theme is that hardware faithfulness often reduces the trusted computing base by moving platform-specific semantics into a smaller, more auditable locus. TrustMee makes verification a code-signing problem for a signed WebAssembly Verification Component rather than hardcoding multiple TEE-specific verifiers into the host (Sinaki et al., 13 Feb 2026). HolBA removes compilers and inlined assembly from the main proof story by working directly on binaries (Palmskog et al., 18 Mar 2025). Proof-Carrying Hardware via IC3 binds a CNF inductive strengthening $W$2 to the shipped hardware checker and lets the consumer validate it with three UNSAT checks against $W$3, $W$4, and $W$5, so validation is independent of trust in the producer (Isenberg et al., 2014).

The literature also records sharp limits. ESBMC-Arduino is limited to the integer/Boolean fragment of IEC 61131-3, abstracts non-linear blocks to nondeterministic outputs constrained to declared ranges, and may return Unknown for function-block-heavy programs because of induction incompleteness (Dantas et al., 9 Jul 2026). VRASED excludes physical attacks, relies on compiler axioms, and does not model caches or pipelines (Nunes et al., 2018). SHIA uses a fixed 500 ms delay and a single serial link in the proof-of-concept, so timing determinism and scalability remain limited (Lewis et al., 11 May 2026). HolBA’s guarantees are only “as faithful to hardware as the ISA model itself,” which leaves microarchitectural timing outside scope (Palmskog et al., 18 Mar 2025).

This suggests that hardware-faithful verification is best understood as a design principle rather than a single formalism. The principle is to place the proof obligation at the layer where the decisive semantics actually live: ADC ranges and two’s-complement wrap-around on a PLC board, latency and sign interpretation in sequential equivalence, vendor-specific quote semantics in attestation, real MCU signals in HW/SW co-design, timing-accurate RTL in microarchitectural security, or executable machine code in binary verification. Across these settings, the central question is not only whether a property is proved, but whether it is proved for the artifact and semantics that will matter when the hardware actually runs.