Source-linked AI summary
LO-FAT: Low-Overhead Control Flow ATtestation in Hardware
Ghada Dessouky, Shaza Zeitouni, Thomas Nyman, Andrew Paverd, Lucas Davi, Patrick Koeberl, N. Asokan, Ahmad-Reza Sadeghi
TL;DR
Static attestation cannot detect runtime control-flow attacks, while software-based control-flow attestation requires instrumentation and incurs performance overhead. LO-FAT uses processor hardware features to capture control flow without instrumenting software; its proof of concept reports no processor stalls and modest hardware costs.
Problem
Method
Results
LO-FAT incurs no processor stalls; on a Virtex-7 XC7Z020 it uses 4% of available registers and 6% of available LUTs.
Source: §6.1 · p. 5, §6.2 · p. 5Takeaways & Limitations
The RISC-V proof of concept demonstrates control-flow attestation for legacy software without processor performance impact.
Source: §8 · p. 7Loop-counter tracking uses dedicated sparse on-chip memory, a constrained resource on low-end embedded devices; tracking granularity can be configured to available memory.
Source: §5.1 · p. 4
Abstract
from arXiv · showhide
Attacks targeting software on embedded systems are becoming increasingly prevalent. Remote attestation is a mechanism that allows establishing trust in embedded devices. However, existing attestation schemes are either static and cannot detect control-flow attacks, or require instrumentation of software incurring high performance overheads. To overcome these limitations, we present LO-FAT, the first practical hardware-based approach to control-flow attestation. By leveraging existing processor hardware features and commonly-used IP blocks, our approach enables efficient control-flow attestation without requiring software instrumentation. We show that our proof-of-concept implementation based on a RISC-V SoC incurs no processor stalls and requires reasonable area overhead.
1 Introduction
Embedded software attacks threaten connected devices, while static attestation misses runtime attacks and software-based control-flow attestation requires instrumentation and incurs performance penalties. LO-FAT proposes hardware-based control-flow attestation intended to avoid those costs while supporting legacy software.
1 Introduction
- Remote attestation checks software on a remote device, but static schemes attest only the initially loaded software and leave runtime attacks unaddressed.Runtime attackers can alter control-flow information through stack or heap corruption.Source: §1 · p. 1
- Control-flow attacks can exploit corrupted pointers, while non-control-data attacks can redirect execution without violating control-flow integrity.Static attestation cannot detect either attack type.Source: §1 · p. 1
- Software control-flow attestation requires applications to be instrumented and runs tracking code on the main processor, incurring performance penalties.Non-instrumented or incorrectly instrumented software cannot be attested.Source: §1 · p. 1
- LO-FAT records control flow in hardware in parallel with the processor, targeting attestation without software instrumentation or processor stalls.It leverages existing processor features and commonly used IP blocks.Source: §1 · p. 2
- The paper contributes an optimization to avoid redundant attestation computation, a RISC-V proof of concept, and evaluations of hardware area and performance.The implementation targets the Pulpino core and single-threaded embedded software.Source: §1 · p. 2
2 Problem Setting and Challenges
Runtime attacks can divert execution from a program’s valid control-flow graph without necessarily changing its binary. LO-FAT targets these attacks with hardware-based control-flow attestation, addressing practical limits of prior software-based attestation.
2 Problem Setting and Challenges
- Runtime attacks can subvert intended execution even when conventional binary attestation sees an unchanged program.A control-flow graph represents the paths a program should follow at runtime.Source: §2 · p. 2
- The attack classes include code-pointer overwrites, non-control-data corruption that redirects execution, and loop-counter corruption that changes loop iterations.Return-oriented programming stitches together benign code gadgets after memory corruption.Source: §2 · p. 2
- Control-flow attestation can report runtime execution paths, but the proposed software approach requires tedious instrumentation and has high performance overhead.LO-FAT targets attack classes 2–4 with a hardware-only solution.Source: §2 · p. 2
3 System Model
LO-FAT lets a verifier check whether a prover’s reported execution path is valid for a supplied input. The protocol relies on static analysis and protected hardware state, with physical attacks and pure data-driven attacks outside its scope.
3 System Model
- The verifier performs one-time offline processing to generate the program’s control-flow graph and expected loop-execution information.The graph can be generated using static or dynamic analysis.Source: §3 · p. 2
- The verifier sends the program input and a freshness nonce; LO-FAT captures branch source–destination pairs and produces a cumulative path authenticator plus loop metadata.The prover signs the resulting path report with a hardware-protected key, and the verifier checks its signature and validity against the graph.Source: §3 · p. 3
- The threat model allows an adversary to modify writable data memory but assumes code and LO-FAT memory remain protected.Physical attacks and attacks that do not affect control flow, including data-oriented programming, are out of scope.Source: §3 · p. 3
4 LO-FAT Design
LO-FAT filters processor execution into control-flow events and handles loops separately to keep path reporting compact. It hashes distinct loop paths once, tracks their iteration counts, and signs the final path report with loop metadata.
4 LO-FAT Design
- The branch filter extracts branch, jump, and return instructions and records each as a source–destination address pair.Non-loop branches are sent for hashing; loop branches are handled by the loop monitor.Source: §4 · p. 3
- LO-FAT identifies loop boundaries and depth at runtime, then encodes each loop path uniquely for tracking.This avoids naively hashing every loop iteration and the resulting combinatorial growth in valid hash values.Source: §4 · p. 3
- Each unique loop path is hashed once; repeated executions increment its on-chip counter instead of triggering further hash operations.The counter records the number of iterations for that path.Source: §4 · p. 3
- At loop exit, LO-FAT assembles loop-path encodings, iteration counts, and indirect-branch targets as metadata and appends it to the final hash.A digital signature covers the hash, metadata, and nonce for the verifier.Source: §4 · pp. 3–4
5 Implementation
LO-FAT detects and compresses control-flow paths in hardware, recording loop paths and iteration counts as auxiliary metadata. It also handles indirect branch targets with configurable encodings and computes a cumulative hash over executed branch addresses.
5.1 Loop Handling
- A link-register heuristic identifies loop entries from non-linking backward branches, while stored entry and exit nodes track iterations and loop termination, including nested loops.Executed branches are filtered into (Src, Dest)-pairs; branches outside loops go directly to the hash engine.Source: §5.1 · p. 4
- The loop monitor tracks loop paths, records each path’s iteration count, and assembles metadata with path encodings, first-occurrence order, and indirect branch targets.A unique path ID indexes loop-counter memory; a zero count marks a path’s first execution, while later counts are incremented.Source: §5.1 · p. 4, §5.2 · p. 5
- Loop-counter memory provides constant-time, single-cycle access but is sparsely used and can constrain low-end devices, so tracking granularity is configurable.When a loop exits, its memory is reused for subsequent loop executions.Source: §5.1 · p. 4
5.2 Handling Indirect Branches in Loops
- Indirect branch targets are re-encoded into configurable n-bit values, limiting tracked targets per loop and trading path granularity against on-chip memory use.The implementation configures n = 4, ℓ = 16, and up to three nested loops, requiring 1.5 Mbits of BRAM.Source: §5.2 · p. 5
5.3 Hash Engine
- The hash engine absorbs each 64-bit (Src, Dest)-pair every clock cycle and hashes the full execution path into measurement A.A small cache prevents pairs from being dropped during the three clock cycles when a full padding buffer cannot accept input.Source: §5.3 · p. 5
6 Evaluation
In simulation, LO-FAT captured and compressed control flow without stalling the processor, while its FPGA implementation used additional logic and BRAM. Its security properties depend on protected control-flow recording and signing, allowing the verifier to check reports against the program’s CFG.
6 Evaluation
- Cycle-accurate RTL simulation on Pulpino with real embedded-application code confirmed capture and compression of branches, loops, and nested loops in uninstrumented software.The prototype targets a single-threaded embedded system and uses the open-source RISC-V Pulpino core.Source: §6.1 · p. 5, §6 · p. 5
6.1 Functionality and Performance
- LO-FAT incurs no attested-software performance overhead, despite internal tracking latency of two cycles for branches and five cycles at loop exit, because it continues processing incoming pairs without stalling.Synthesis indicates a maximum 80 MHz clock frequency on a Virtex-7 XC7Z020.Source: §6.1 · p. 5
- The length of auxiliary metadata sent to the verifier depends on executed loops, distinct paths per loop, and indirect branch targets.The implementation’s memory requirements depend on configured limits for indirect branches and nested loops.Source: §6.1 · p. 5, §6.2 · p. 5
6.2 Area
- On a Virtex-7 XC7Z020, LO-FAT uses 4% of available registers, 6% of available LUTs, and 49 36Kbit BRAMs, averaging 20% additional logic overhead to Pulpino.Most BRAMs serve sparse loop path-indexed memories for constant-time, single-cycle access.Source: §6.2 · p. 5
6.3 Security
- The control-flow recording memory is assumed protected, and hardware extensions must receive every control-flow event to ensure complete recording.The signing key is assumed protected in hardware-secure memory; the challenge nonce provides freshness, and message tampering is detectable.Source: §6.3 · p. 6
- Given protected recording and signing, LO-FAT’s report is accurate, complete, authentic, and fresh; the verifier can use the program CFG to detect control-flow and non-control-data attacks.The verifier is assumed to know the immutable program code through static attestation at boot.Source: §6.3 · p. 6
7 Related Work
Prior approaches address static attestation, selected runtime properties, or tracing, but the cited work does not attest machine-code control flow in the way LO-FAT targets. The paper contrasts LO-FAT with C-FLAT and hardware tracing and security mechanisms on instrumentation, coverage, and overhead.
Related work
- Static, software-based, and property-based attestation approaches do not attest control flow at machine-code instruction level.Prior runtime work includes program-data invariants, module launch order, and dynamic taint analysis; Dyn-IMA does not cover non-control-data attacks and incurs high overhead.Source: §7 · p. 6
- C-FLAT attests fine-grained control flow but requires control-flow instrumentation and complete offline binary coverage, whereas LO-FAT monitors every executed branch in hardware without performance overhead.C-FLAT’s attestation overhead grows linearly with the number of control-flow events.Source: §7 · p. 6
- Processor tracing and debug mechanisms have overhead or report information unsuited to control-flow attestation; Intel Processor Trace reports events inferable from static analysis, and ARM high-throughput tracing typically requires proprietary hardware.Last Branch Record and Branch Trace Store are also described as too costly for attestation.Source: §7 · p. 6
- Sofia enforces control-flow integrity using encrypted instructions and runtime MAC checks, but requires software instrumentation and incurs execution-time overhead up to 110%.Other hardware-assisted security architectures can impose high memory and logic complexity as the number of IP blocks increases.Source: §7 · p. 6
8 Conclusion
LO-FAT is presented as a hardware-based scheme for precise detection of remote memory-corruption attacks in embedded software. Its Pulpino proof of concept reports no performance impact on attested software, with logic and on-chip memory overhead.
Conclusion
- The Pulpino proof of concept reports no performance impact on attested software, at the expense of minimal logic overhead and on-chip memory.LO-FAT monitors, measures, and reports program behavior by intercepting control-flow events, without code instrumentation, compiler-toolchain changes, or ISA extensions.Source: §8 · p. 7