REVIEW 5 major objections 5 minor 1 cited by
ENOLA: Linear-Space and Low-Overhead Control-Flow Attestation for Microcontroller-based Systems
T0 review · 5 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash
Pith's one-line read ENOLA's authenticator—a per-basic-block occurrence count plus two chained pointer-authentication measurements—achieves linear space complexity, making whole-program attestation practical on low-end microcontrollers.
desk verdict ENOLA has a genuinely new linear-size authenticator and the first low-end MCU evaluation, but its security claim rests on an unproven code-scanner completeness assumption and the performance abstract overclaims. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The central mechanism is the pair of chained measurement chains plus the occurrence-count trace. The trace $T_O$ is a table indexed by basic-block start addresses, updated in the secure-world attestation engine, which gives $O(1)$ per-update cost and makes the authenticator size proportional to the number of basic blocks that actually executed. The two measurements $M_f$ and $M_b$ are generated inline in the normal world using the $pacg$ instruction, which produces a keyed QARMA PAC of a value using the previous measurement as the modifier; the state lives entirely in reserved registers $r10/r11$ and is never written to memory. The compiler instruments destination basic blocks and return sites to issue these $pacg$ operations, and the code scanner checks that no other normal-world code can write to the PA key registers or to $r10/r11$. Verification is a backtracking abstract execution over the CFG that consumes the occurrence counts and recomputes the chains.
What would settle it
A reachable normal-world instruction or ROP gadget that writes to $r10$, $r11$, or a $pac\_key\_*$ register and is not flagged by the ENOLA code scanner would falsify the security claim; a concrete experiment is to link a pre-compiled library that uses $r10/r11$ as general-purpose registers (or contains a single $mov\ r10, ...$ / $pop\ \{r10, pc\}$ gadget), run the scanner, and then demonstrate that a hijack reaching that sequence can forge the chained measurements without detection.
Extended reading notes
Core claim
The paper's central discovery is that a control-flow attestation authenticator can be compressed to linear space without losing the ability to verify the executed path. The authenticator is $Auth = (T_O, \langle M_f, M_b\rangle)$, where $T_O$ records, for each basic block, how many times it was entered during the run, plus a bounded list of any destinations that are not valid basic block starts; any such destination immediately flags an illegal jump. The forward measurement $M_f$ is a chain of pointer-authentication codes over the destination addresses of forward control-flow transfers, and the backward measurement $M_b$ is a chain over return addresses, both computed as $M_i = H_{K_m}(M_{i-1}, d_i)$ using the ARMv8.1-M $pacg$ instruction. The two chains are held in reserved general-purpose registers $r10$ and $r11$, and the key is loaded into the PA key registers only by the secure-world attestation engine. The verifier replays a backtracking abstract execution of the control-flow graph, using the occurrence counts to choose among branch targets, and recomputes both chains to compare against the received values. On the Cortex-M85, the authenticator size is shown to scale with the number of distinct basic blocks executed, not with the number of control-flow events, and to stay under about 1.2 KB for applications with more than 5,000 basic blocks.
Load-bearing premise
The security argument depends on the ENOLA code scanner being able to statically find every instruction or ROP gadget anywhere in normal-world code—the attested program, libraries, and kernel—that writes to the PA key registers or to the reserved measurement registers $r10/r11$; if any such write goes unnoticed, an attacker who can reach it can tamper with the measurement chains.
Editorial extensions
If this is right
- Authenticator sizes become compile-time predictable: for a program with $|V|$ basic blocks the report is $O(|V|)$ plus a small constant, so whole programs with thousands of basic blocks (e.g., RSA with 5,480 basic blocks) produce reports around 1.2 KB or less.
- Measurement computation overhead drops by more than two orders of magnitude relative to software BLAKE2s/SHA-256 (12 cycles per $pacg$ vs thousands of cycles), making runtime overhead acceptable on a single-core, 25 MHz Cortex-M85.
- Whole-program, basic-block-granularity attestation becomes feasible on commodity ARMv8.1-M devices with TrustZone and the Pointer Authentication extension, without custom CPU modifications and without restricting attestation to snippets or O0 builds.
- The occurrence trace lets the verifier detect deviations such as altered loop iteration counts or illegal indirect targets, since any non-zero occurrence count for a block must be explainable by a valid path through the CFG.
Reading between the lines
- The same authenticator design could be extended to attest RTOS tasks by maintaining a separate occurrence table per task and resetting or rekeying the measurement chains at context switch; the paper lists multitask attestation as future work.
- Any ISA with a hardware keyed one-way primitive (for example, a future RISC-V scalar-crypto extension) could host a similar scheme, provided the key can be protected and the chain state kept in registers.
- The load-bearing scanner assumption could be retired by enforcing write-protection on $r10/r11$ and the PA key registers in the memory-protection unit, or by trapping any unapproved write; this would let pre-compiled libraries use those registers safely.
- A pure occurrence count loses temporal ordering of basic blocks; the backward-return chain partially restores order for returns, and a forward chain extended with a small per-loop counter could encode more ordering information at constant space cost, which the authors did not explore.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper presents ENOLA, a control-flow attestation scheme for ARMv8.1-M microcontrollers. The authenticator is Auth=(T_O,<M_f,M_b>), where T_O is a per-basic-block occurrence count and M_f/M_b are chained pointer-authentication (PAC) values over forward branch destinations and return addresses. The paper claims O(|V|) space complexity, hardware-assisted measurement computation via ARM Pointer Authentication, and protection of measurements by reserving r10/r11. The implementation is described as LLVM passes plus an attestation engine, and the evaluation is carried out on a Cortex-M85 using Embench, wolfSSL, and a syringe-pump application. The central security argument relies on an 'ENOLA code scanner' that is asserted to rule out any normal-world instruction or ROP gadget that can write to the PA key registers or to the reserved measurement registers.
Significance. If the security guarantees hold, the linear-size authenticator is a meaningful step beyond prior CFA schemes, whose trace or measurement size is O(n) or O(2^|V|). The paper also provides a useful first evaluation point on a single-core Cortex-M85 at O2/Oz, on programs larger than those previously attested, and it makes the source code available. The plots in Figure 8 support the claimed linear dependence on the number of unique basic blocks, and no fitted parameters are used in the central argument. However, the security claim is not established: the code-scanner completeness assumption is unproven, the non-secure callable trampolines appear directly exploitable, and the collision-probability statement is internally inconsistent. The abstract's performance claim is also contradicted by the paper's own averaged overhead numbers. These issues are load-bearing for the paper's main claims, so I recommend major revision.
major comments (5)
- [Section 7.4, Figure 4b] The paper's own average execution-time overheads on the common Embench applications are 322.20% (O2), 278.64% (O2 with unrolling), 284.54% (Oz), and 431.53% (Oz with unrolling), while the Blast numbers cited in the same section are 185% and 175%. These numbers do not support the abstract's claim of 'lower or comparable performance to the existing works.' The performance claim should be revised to report these overheads honestly and to state precisely which applications and comparison configurations support the weaker statement that ENOLA outperforms Blast on at least one optimization level.
- [Section 4.3, Section 4.5, Section 5 P2] The security of M_f/M_b depends on the ENOLA code scanner proving that no normal-world instruction or ROP gadget can write to the PA key registers or to r10/r11. This is asserted as a 'comprehensive analysis' but no completeness argument is provided, and Section 6 states that the scanner is a 93-line Python tool built on angr, which is not a complete disassembler. Because the PA hardware is an unrestricted oracle in the normal state, one missed gadget that writes r10/r11 (for example, a pacg with rd=r10) would allow the attacker to continue the chained measurement for an arbitrary path. Section 4.5 further concedes that pre-compiled libraries using r10/r11 can spill measurements to memory. The authors need either a formal scanner-correctness argument over the full normal-world image, including libraries and kernel, or an explicit restriction of the threat model that makes this assumption valid; otherwise prerequisite P2 is not established.
- [Section 4.4, Section 5 P4] The report_direct and report_indirect interfaces are exposed as non-secure callable (cmse_nonsecure_entry) trampolines. The attestation engine reads the direct destination from lr and the indirect destination from r0 (Listings 6-7), so any normal-world code that can branch to the trampoline can set these registers and inject arbitrary entries into T_O. The compiler's prohibition on direct world-switch calls only constrains the generated code, not a runtime attacker, and the SFI hardening mentioned in Section 5 is described as 'can adopt' rather than implemented. This undermines the claim that Auth and T_O cannot be manipulated; the trampoline interfaces need an implemented protection mechanism, such as enforced SFI or caller authentication, before the security claim can be accepted.
- [Section 5 P3 and Table 2] Table 2 states that pacg stores a 32-bit PAC in a general-purpose register, but Section 5 attributes to QARMA a '64-bit modifier' and a collision probability of about 2^-60. These statements are internally inconsistent: with a 32-bit stored PAC the per-tag collision probability is at most about 2^-32, not 2^-60. Because the forgery resistance of the chained measurements is the basis for P3, the authors must correct the bit-length analysis and re-derive the security parameter, including the effect of chaining and the oracle available to an attacker with normal-world code execution.
- [Section 4.6, Algorithm 1, and Section 4.5] The verifier updates M_f at a program exit by computing HKm(vc.s, M'_f) at Algorithm 1 line 11, but the instrumentation described in Section 4.5 updates M_f at the destination of each forward branch via an instrumented pacg at the start of the destination block. If the exit block is reached through a forward branch, the verifier appears to double-count it; if the program has no forward branch or a fall-through-only path, the verifier appears to include an exit block that was never instrumented. As written, the verification algorithm and the instrumentation are inconsistent, which would cause legitimate executions to fail verification. The authors should clarify the intended measurement update rule and reconcile the algorithm with the compiler pass.
minor comments (5)
- [Section 4.3] The paragraph beginning 'This goal is accomplished by verifying that all programs operating in the normal state do not contain any unauthorized instructions...' appears twice nearly verbatim; one copy should be removed.
- [Abstract and Section 10] The abstract and conclusion repeat the 'lower or comparable performance' claim; both should be revised to match the average overhead data reported in Section 7.4.
- [Table 5] The HMAC row has a malformed Edges column entry, '24,2523,83', which appears to concatenate the O2 and Oz values; please split it into two numbers.
- [Figure 4] The label 'Not Evaluated by Blast' appears for several applications without an explanation of which applications Blast actually evaluated; the figure or caption should state the exact comparison set.
- [Listings 6-7] The report_direct interface is described as obtaining the destination from lr, but after a 'bl report_direct' the lr contains the address of the instruction following the call, not the target basic block's start address. Please state explicitly how vi.s is reconstructed or why an in-block address is a valid T_O entry.
Circularity Check
No significant circularity found; ENOLA's O(|V|) authenticator is definitional and its overhead/Auth-size claims are benchmarked externally.
full rationale
I find no circularity. The central complexity claim O(|V|) follows directly from the definition of T_O as a set of per-basic-block occurrence pairs indexed by vi.s (plus a bounded list of illegal targets), and the O(1) measurement claim follows from the fixed-size registers r10/r11 holding M_f and M_b; this is an analytic property of the construction, not a fitted prediction. The empirical claims about Auth size, code-size overhead, and execution-time overhead are evaluated against external artifacts (Embench, wolfSSL, the syringe pump) and compared with prior schemes (C-FLAT, OAT, Blast), so they are not self-referential. The paper's citations to the authors' own prior work (SHERLOC [58], InsectACIDE [63]) appear only in related-work discussion and are not load-bearing for the main complexity or security results. The code-scanner completeness assumption in Section 4.3 is a genuine soundness assumption about static analysis coverage, but it is not an input-output equivalence or a fitted parameter renamed as a prediction; it belongs to security-correctness risk rather than circularity. Accordingly, the derivation chain is self-contained and the score is 0.
Assumptions & free parameters
assumptions (4)
- domain assumption The control-flow graph of the attested program can be treated as complete, with all indirect targets known.
- domain assumption Secure boot, W^X code immutability, and TrustZone guarantees keep the attestation engine, keys, and instrumented code unmodified.
- domain assumption The ENOLA code scanner can enumerate every instruction or ROP gadget in all normal-world code that writes to the PA key registers or to reserved registers r10/r11.
- domain assumption The ARMv8.1-M PAC primitive (QARMA) provides a collision-resistant keyed MAC with forgery probability about 2^-60.
Cite this review
Pith. "Pith review of ENOLA: Linear-Space and Low-Overhead Control-Flow Attestation for Microcontroller-based Systems." pith.science (2026). https://pith.science/paper/5TC2R7S7
@misc{pith2026250111207,
author = {Pith},
title = {Pith review of: ENOLA: Linear-Space and Low-Overhead Control-Flow Attestation for Microcontroller-based Systems},
year = {2026},
howpublished = {\url{https://pith.science/paper/5TC2R7S7}},
note = {Machine review of arXiv:2501.11207}
}
read the original abstract
Control-Flow Attestation (CFA) aims to precisely verify execution paths to a remote verifier. However, existing solutions are fundamentally incompatible with resource-constrained, microcontroller-based systems due to the following reasons: (1) the overhead of transmitting measurement and trace data scales poorly (i.e., often exponentially) with the number of basic blocks or linearly with the length of execution traces, making such approaches impractical even on high-end microprocessor-based systems and entirely infeasible on microcontrollers; (2) cryptographic keys and measurement data are typically stored in memory, rendering them vulnerable to cold boot and memory corruption attacks, which is a serious threat for field-deployed devices; and (3) reliance on software-based measurements, combined with frequent context switches between the Rich Execution Environment (REE) and the Trusted Execution Environment (TEE), introduces significant performance overhead. In this paper, we present ENOLA, a linear-space and low-overhead control-flow attestation solution for microcontroller-based systems. ENOLA achieves linear transmission complexity with basic blocks, guaranteeing its scalability for larger programs. Moreover, ENOLA uses hardware-assisted measurement computation present in off-the-shelf devices, and avoids key storage in memory. ENOLA also allocates general-purpose registers for measurements to thwart memory corruption attacks. ENOLA significantly reduces context switching overhead by eliminating transitions from REE to TEE for backward-edge measurements. We developed the ENOLA compiler using LLVM passes and a custom attestation engine targeting the ARMv8.1-M architecture. Our evaluation shows that ENOLA reduces data transmission overhead by an average of 52x on the Embench, while maintaining performance comparable to (or exceeding) that of existing approaches.
Figures
Figures from the paper (5 more)
Forward citations
Cited by 1 Pith paper
-
On the Verification of Control Flow Attestation Evidence
SABRE automatically localizes and patches buffer overflow and use-after-free vulnerabilities using verbatim control-flow attestation logs and the binary alone, with no source code or memory snapshot.
Reviewed August 10, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.