{"id":"663c2157-441d-46af-9faf-48901b9c85e1","arxiv_id":"2501.11207","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"ENOLA produces linear-size control-flow attestation reports on a Cortex-M85 by combining per-block occurrence counts with two hardware PAC chains.","lead":"ENOLA instruments microcontroller programs so that every basic block's execution count and two hardware-checked hash chains are sent to a verifier, making control-flow attestation data grow linearly with program size rather than with execution length. It is the first CFA design tested on a commercial single-core Cortex-M85, using ARM Pointer Authentication as a fast measurement primitive.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The security argument hinges on the code scanner proving that no normal-world instruction or ROP gadget can tamper with r10/r11 or the PA key registers; this completeness is not established, so attestation may be forgeable.","rationale":"The strongest claim, linear O(|V|) authenticator size, is well supported: T_O has at most |V| entries plus a separate small t_i set, and the wolfSSL experiments confirm scaling. The security argument, however, is the weak point. For attestation to be meaningful, an attacker who hijacks control flow must not be able to produce a valid Auth for a fake path. ENOLA's defense against this is the scanner's guarantee that no normal-world code can modify r10/r11 or the PA key registers. If that guarantee fails, the PA hardware becomes a MAC oracle the attacker can use, and the report trampolines allow T_O fabrication. The paper asserts scanner completeness without proof and acknowledges the library-spill risk. A missed gadget is not a theoretical edge case: angr-based binary analysis is not a sound over-approximation for obfuscated or hand-written code. I also note that the PAC collision probability claim (2^-60) in Section 5 is hard to reconcile with a 32-bit PAC, but this is secondary to the scanner issue. Given that the paper is an implementation-focused systems contribution, the appropriate outcome is conditional acceptance: the security claim requires either a stronger scanner argument or an explicit threat-model restriction. This does not change the reader's verdict.","tokens_in":25987,"tokens_out":8157,"duration_ms":82119,"concrete_test":"Run an exhaustive gadget and instruction scan on the shipped ENOLA-instrumented binaries (Embench and wolfSSL at O2/Oz) and on typical pre-compiled libraries with r10/r11 usage, using angr as well as an independent Capstone-based disassembler. Flag any basic block outside ENOLA's own instrumentation that contains: (1) a write to r10/r11 (mov, pop, ldr, or pacg/autg with rd=r10/r11), (2) an indirect branch (bx/blx) that can target the NSC trampoline addresses with attacker-controlled lr/r0, or (3) a read of r10/r11 into a caller-saved register. If any such gadget is found, the scanner-completeness assumption is falsified and the security claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that ENOLA provides secure CFA depends on the ENOLA Code Scanner (Section 4.3) eliminating all normal-world instructions or ROP gadgets that write to the PA key registers or to the reserved measurement registers r10/r11. This is load-bearing because the PA hardware is an unrestricted chosen-input MAC oracle in the REE: an attacker with code execution can execute pacg with arbitrary rn/rm and read the output, and can invoke the report_direct/report_indirect trampolines to fabricate the occurrence trace T_O. If any gadget allows writing r10/r11 (e.g., a pacg with rd=r10) or gaining read access to r10, the attacker can compute a valid M_f/M_b chain for an arbitrary path and forge Auth. The paper asserts that the scanner performs a 'comprehensive analysis' but provides no completeness proof; the implementation uses angr for disassembly, which is known to miss instructions in some binaries. Section 4.5 concedes that pre-compiled libraries using r10/r11 can spill measurements to memory, creating direct exposure. Section 5's P4 mitigation (SFI hardening of trampoline calls) is described only as 'can adopt', so the trampoline interfaces remain callable by any normal-world code with an attacker-controlled lr/r0. Thus, if the scanner misses one gadget or library, ENOLA's attestation is forgeable, undermining the central security claim even though the O(|V|) space complexity result is sound.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":26198,"tokens_out":12941,"duration_ms":126639,"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":[{"comment":"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":"Section 7.4, Figure 4b"},{"comment":"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":"Section 4.3, Section 4.5, Section 5 P2"},{"comment":"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":"Section 4.4, Section 5 P4"},{"comment":"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":"Section 5 P3 and Table 2"},{"comment":"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.","section":"Section 4.6, Algorithm 1, and Section 4.5"}],"minor_comments":[{"comment":"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.","section":"Section 4.3"},{"comment":"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.","section":"Abstract and Section 10"},{"comment":"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.","section":"Table 5"},{"comment":"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.","section":"Figure 4"},{"comment":"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.","section":"Listings 6-7"}],"recommendation":"major_revision","confidential_remarks":"The linear-size authenticator and the Cortex-M85 evaluation are genuinely useful contributions, but the security model is currently overclaimed. The scanner completeness and NSC trampoline issues are not merely presentation problems; they affect the core unforgeability argument and need to be addressed, either by a formal correctness argument or by an explicitly restricted threat model. The PAC bit-length inconsistency and the verification-algorithm/instrumentation mismatch are also load-bearing and should be corrected before publication."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"ENOLA is worth reading for the authenticator design alone. Combining per-basic-block occurrence counts with two PAC chains (forward destinations, return addresses) yields O(|V|) attestation data, and the authors actually built it for ARMv8.1-M and ran it on a Cortex-M85 over Embench and wolfSSL. That is the first believable demonstration of whole-program CFA on a low-end single-core MCU, and the paper's own plots support the linear-space claim. I give it credit for shipping the code, for using O2/Oz rather than the unrealistic O0, and for comparing against Blast on the same benchmarks.\n\nThe main soft spot is the security argument, and it is load-bearing. The PA unit in the normal world is a chosen-input MAC oracle: any code that can write r10/r11 or the PA key registers can recompute the M_f/M_b chains for an arbitrary path. The code scanner is supposed to guarantee no such instruction or gadget exists anywhere in normal-world code, but that completeness is asserted, not proven. Angr-based disassembly is known to miss instructions, and the paper itself concedes pre-compiled libraries using r10/r11 can spill the measurements to memory. The SFI hardening of trampoline calls is described as \"can adopt,\" not implemented. So the scheme is secure only under an unverified global property of the entire REE software stack. That needs either a proof, a substantially restricted threat model, or a hardware mechanism that blocks normal-world writes to those registers. The complexity result stands independently, but the \"secure CFA\" claim does not.\n\nSecond issue is the abstract. \"Lower or comparable performance\" is not what the paper's own averages say: ENOLA's average execution overhead on common Embench applications is 278-431% versus Blast's reported 185%/175%, and the comparison is apples-to-oranges (basic-block vs function-level granularity, different optimization levels, different CPUs). The paper's detailed discussion is more honest than the abstract, but the abstract overclaims.\n\nMinor editorial point: Section 4.3 repeats the code-scanner paragraph nearly verbatim.\n\nThe citation pattern is fine; no circularity, no fitted parameters. This is a serious systems paper with a real contribution, but it needs major revision before acceptance. I'd send it to review, not desk reject, with instructions that the security model be tightened and the performance claims rephrased.","headline":"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.","tokens_in":26815,"tokens_out":3984,"would_cite":true,"duration_ms":41267,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["control-flow attestation","embedded systems","pointer authentication","ARMv8.1-M","TrustZone","basic block occurrence trace","linear space complexity","remote attestation"],"falsifier":"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.","tokens_in":25715,"feed_emoji":"🔐","tokens_out":14274,"duration_ms":111908,"temperature":0.7,"pith_summary":"Control-flow attestation (CFA) lets a remote verifier confirm that an embedded device executed a program along a legitimate control-flow path. Until now, CFA reports have either grown with the execution trace or exponentially with the number of basic blocks, restricting attestation to small snippets. This paper claims a new authenticator format that is linear in the number of basic blocks: a per-basic-block occurrence count plus two chained keyed measurements, one over forward branch targets and one over return addresses. Because the measurements are computed by ARM Pointer Authentication hardware (the pacg instruction) rather than software hash functions, and the occurrence trace is recorded in a TrustZone-secured attestation engine, ENOLA reports whole-program attestation on a single-core Cortex-M85 with much smaller authenticators than prior schemes and comparable or lower overhead. If correct, this makes CFA practical for real microcontroller firmware rather than toy operations.","feed_headline":"Attestation reports now linear in basic blocks, not execution length","feed_subtitle":"ENOLA pairs a per-block occurrence count with chained pointer-auth hashes, making attestation practical on a Cortex-M85","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines control-flow attestation and the measurement-based authenticator; provides the O(2^|V|) space baseline and the syringe pump evaluation harness used for comparison.","marker":"[7]"},{"why":"OAT's hybrid trace/measurement scheme is the main prior complexity target; its O(n) trace-space bound is the one ENOLA's O(|V|) result improves on.","marker":"[57]"},{"why":"Blast is the strongest prior scalability result at function granularity; ENOLA's Embench and whole-program evaluations directly compare code size, execution time, and auth size against it.","marker":"[65]"},{"why":"LO-FAT demonstrates hardware-assisted CFA but requires CPU modification; it is the reference point for ENOLA's claim of using commodity hardware instead.","marker":"[29]"},{"why":"Specifies the QARMA block cipher that backs ARM Pointer Authentication, giving the 2^{-60} collision probability cited in the security analysis.","marker":"[18]"},{"why":"PACStack introduces chained PACs over return addresses; ENOLA adopts the same chaining technique for its forward and backward measurement chains.","marker":"[44]"},{"why":"Documents the ARM Pointer Authentication extension as a hardware building block, supporting ENOLA's premise that the measurement primitive is available on commodity ARMv8.1-M parts.","marker":"[45]"}],"fun_headline_variants":["Attestation size now scales with basic blocks, not events","ENOLA: linear-space control-flow attestation for MCUs","Hardware PAC chains make attestation practical on Cortex-M85","Compressed attestation: counts plus chained hashes in registers","ENOLA shrinks attestation to under 1.2 KB for 5K blocks"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Attestation size now scales with basic blocks, not events","ENOLA: linear-space control-flow attestation for MCUs","Hardware PAC chains make attestation practical on Cortex-M85","Compressed attestation: counts plus chained hashes in registers","ENOLA shrinks attestation to under 1.2 KB for 5K blocks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000177,"raw_usage":{"total_tokens":1338,"prompt_tokens":1038,"completion_tokens":300,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":654,"completion_tokens_details":{"reasoning_tokens":207}},"tokens_in":654,"tokens_out":300,"duration_ms":3455,"temperature":1.0,"reasoning_tokens":207,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T18:32:33.368540+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"C-FLAT: control-flow attestation for embedded systems software","cited_arxiv_id":null,"evidence_quote":"Defines control-flow attestation and the measurement-based authenticator; provides the O(2^|V|) space baseline and the syringe pump evaluation harness used for comparison."},{"cited_title":"Oat: Attesting operation integrity of embedded devices","cited_arxiv_id":null,"evidence_quote":"OAT's hybrid trace/measurement scheme is the main prior complexity target; its O(n) trace-space bound is the one ENOLA's O(|V|) result improves on."},{"cited_title":"Whole-program control-flow path attestation","cited_arxiv_id":null,"evidence_quote":"Blast is the strongest prior scalability result at function granularity; ENOLA's Embench and whole-program evaluations directly compare code size, execution time, and auth size against it."},{"cited_title":"Lo-fat: Low-overhead con- trol flow attestation in hardware","cited_arxiv_id":null,"evidence_quote":"LO-FAT demonstrates hardware-assisted CFA but requires CPU modification; it is the reference point for ENOLA's claim of using commodity hardware instead."},{"cited_title":"The QARMA block cipher family","cited_arxiv_id":null,"evidence_quote":"Specifies the QARMA block cipher that backs ARM Pointer Authentication, giving the 2^{-60} collision probability cited in the security analysis."},{"cited_title":"PACStack: an Authen- ticated Call Stack","cited_arxiv_id":null,"evidence_quote":"PACStack introduces chained PACs over return addresses; ENOLA adopts the same chaining technique for its forward and backward measurement chains."},{"cited_title":"PAC it up: Towards pointer integrity using ARM pointer au- thentication","cited_arxiv_id":null,"evidence_quote":"Documents the ARM Pointer Authentication extension as a hardware building block, supporting ENOLA's premise that the measurement primitive is available on commodity ARMv8.1-M parts."}],"review_version":1}