{"id":"0b9d96d1-f5cf-43d9-a99a-f2beefbf30ca","arxiv_id":"2501.09216","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"EILID is a hybrid hardware/software control-flow integrity architecture for low-end IoT devices that combines a shadow stack with function-level forward-edge checking on top of the CASU root of trust.","lead":"EILID is a security add-on for tiny IoT chips that watches where the program goes and resets the chip if a return address or function call has been tampered with. It combines compile-time code changes with a protected shadow stack and a small hardware monitor, and the authors report low overhead on an open MSP430 prototype.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Figure 8 omits the shadow-stack push for indirect calls, so the claimed backward-edge CFI invariant is not established and likely fails on legitimate function-pointer calls.","rationale":"I read the paper's central claim as stated in the abstract: fine-grained backward-edge and function-level forward-edge CFI via semi-automatic instrumentation and a secure shadow stack. For backward-edge CFI to hold, every call, including an indirect call, must push a matching shadow-stack entry, and every return must pop and validate it. The paper's Section IV-A asserts such an invariant, but the only figure showing indirect-call instrumentation, Fig. 8, does not include the store side. This is the same weak point the reader identified in their weakest_assumption, and I agree it is the most load-bearing uncertainty: if the instrumenter really leaves indirect calls uninstrumented for the backward-edge store, then ordinary function-pointer calls would reset the device, and the claimed integrity guarantee is not achieved. The concrete check is straightforward: inspect the output of EILIDinst on a small indirect-call program and run it in the provided simulator. This is a correctness risk internal to the paper's own described design, not a disagreement with the field. I do not treat the missing figure detail as proof of fraud or even as proof of a final prototype failure; the released script may insert a store even though Fig. 8 omits it. But the manuscript as written does not establish the invariant, and the central claim should remain conditional until the instrumentation output or a corrected figure settles it. The reader's verdict of CONDITIONAL is therefore appropriate, and my stress-test does not move it.","tokens_in":11513,"tokens_out":5509,"duration_ms":60303,"concrete_test":"Check the released EILIDinst on the anonymous repository: compile a minimal MSP430 program with `void (*fp)(void)=target; fp();` using the documented three-pass flow, and inspect the final instrumented assembly immediately before the `call r13` instruction. If the only inserted call is `NS_EILID_check_ind` with no `NS_EILID_store_ra`, run the binary in the openMSP430 behavioral simulation; a legitimate indirect call should then reset because the shadow-stack pop at `ret` does not match any entry pushed for that call, refuting the central backward-edge claim as stated. If the script actually inserts a store, the test confirms the intended invariant, and Fig. 8 plus the text still need correction to document it.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that EILID enforces fine-grained backward-edge CFI by instrumenting every function call so that its return address is pushed onto the shadow stack, and every return is checked against that stack. Section IV-A states this invariant, and Fig. 4 implements the check side for RET. However, Fig. 8, the only presented instrumentation for an indirect call, inserts only `mov r13, r6; call #NS_EILID_check_ind; call r13`. There is no `NS_EILID_store_ra` or equivalent before the `call r13`. Since the MSP430 `CALL` pushes the return address only onto the main stack, not the shadow stack, the callee's subsequent `RET` check pops whatever is on top of the shadow stack, which corresponds to a different call site. A legitimate indirect call through a function pointer would therefore trigger a mismatch and reset, or, if the check is not executed on that path, the return edge is left unprotected. The text promises that 'before each function call site' the return address is stored; Fig. 8 violates that promise for indirect call sites. This is not a drawing nit: it is exactly the invariant needed for the headline claim of backward-edge integrity for low-end MCU software, where function-pointer calls are ordinary C. The address-shift correction in Section V-A is a secondary concern, but the indirect-call instrumentation gap is the most load-bearing because it directly undermines the claimed protection for a standard control-flow edge.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"EILID is a hybrid root-of-trust architecture that adds control-flow integrity to low-end MCUs (prototyped on openMSP430) on top of the CASU active-RoT platform. The instrumenter (EILIDinst) rewrites compiled assembly to store return addresses on a hardware-protected shadow stack before direct calls, to check them before returns, to store and verify interrupt contexts at ISR entry/exit, and to check indirect-call targets against a table of function entry points. EILIDsw is a small trusted ROM routine that maintains the shadow stack, and EILIDhw is the CASU-derived hardware that resets the device on a CFI violation. The paper evaluates compile-time, binary-size, and run-time overhead on seven small applications and reports hardware cost in LUTs and registers relative to prior CFI/CFA designs.","tokens_in":11791,"tokens_out":10374,"duration_ms":102577,"significance":"The contribution is potentially significant: if the described instrumentation actually enforces the claimed invariants, EILID would be a rare prevention-based real-time CFI solution for MCUs without MPU/MMU support, with modest reported overhead (7.35% average run-time in simulation, 10.78% binary-size growth). The concrete openMSP430 prototype and the three-build address-correction scheme are useful practical artifacts, and the source code is released. The main caveat is that the security argument is not fully established: the indirect-call instrumentation shown in Figure 8 violates the stated shadow-stack push invariant, and the paper does not supply a correctness invariant or verification for the instrumenter and trusted software. These issues are load-bearing for the central claim.","major_comments":[{"comment":"Figure 8 instruments an indirect call as `mov r13, r6; call #NS_EILID_check_ind; call r13`. This sequence verifies only that the target is in the function-entry table; it does not store the return address of the `call r13` on the shadow stack. The MSP430 `CALL` pushes the return address on the main stack only, so when the callee later executes the instrumented `RET` check of Figure 4, `NS_EILID_check_ra` will pop whatever entry is currently on top of the shadow stack, which belongs to an earlier direct call (or to the initial state). Legitimate indirect calls through function pointers will therefore either cause spurious resets or leave the backward edge unprotected if the check is skipped. This directly contradicts the Section IV-A statement that \"before each function call site\" the instrumented code stores the return address on the shadow stack, and it invalidates the claimed P1 guarantee for programs that use indirect calls. The paper must add the missing shadow-stack store to the indirect-call instrumentation and state how the return address is computed and passed, or explain an alternative mechanism by which `NS_EILID_check_ind` also pushes the return address.","section":"Section IV-A and Figure 8"},{"comment":"The three-build address-shift correction is described only by example. The paper does not specify the invariant that the final pass must satisfy, such as requiring that for every call site the immediate operand of the inserted `mov #imm, r6` equals the address of the instruction following the corresponding `call` in the final binary, nor does it argue why two re-builds are sufficient for all address references in a given program, including function-table entries and ISR-context offsets. Since the security checks compare run-time addresses against these compile-time constants, a single stale offset would produce false resets or missed detections. This procedure needs a precise specification and ideally a test or verification over the benchmark set.","section":"Section V-A"},{"comment":"The security argument for the trusted software is informal. The paper states that EILIDsw is immutable and that EILIDhw resets on violation, but it does not analyze whether an adversary who controls non-secure registers can invoke the entry section with an arbitrary dispatch value r4, corrupt the shadow-stack index r5, or exploit nested interrupts to make the shadow-stack push/pop sequence inconsistent. A precise invariant for the shadow-stack index across calls, returns, and ISR preemption is needed; without it, the claim that EILID \"ensures software execution integrity\" is not fully supported. This is not a demand for a machine-checked proof, but the invariant should be stated and argued.","section":"Section IV-B and V-B"}],"minor_comments":[{"comment":"The platform is listed as \"opemMSP430\"; it should be \"openMSP430\".","section":"Table I"},{"comment":"The figures call the routines `NS_EILID_store_rfi` and `NS_EILID_check_rfi`, while the text names them `NS_EILID_store_rai` and `NS_EILID_check_rai`; please unify the names.","section":"Figures 5 and 6"},{"comment":"The sentence \"EILIDhw does not require any modification, except for the secure memory extension reserved for the shadow stack\" is internally contradictory; it should be rephrased to state exactly which CASU components are modified.","section":"Section III-A"},{"comment":"Run-time overhead is reported from behavioral simulation rather than from the FPGA prototype; please clarify whether the simulation frequency (100 MHz) matches the synthesized design and whether interrupt timing was modeled.","section":"Section VI"},{"comment":"Table III says r4 is \"Used as an argument of S_EILID_init()\", but Section V-B says r4 determines which S_EILID function is invoked, e.g., r4==1 branches to S_EILID_store_ra(); the roles should be described consistently.","section":"Table III and Section V-B"},{"comment":"The text refers to \"Figure II shows instruction sets\", but the instruction-set summary is Table II; the cross-reference should be corrected.","section":"Section IV"}],"recommendation":"major_revision","confidential_remarks":"To the editor: the indirect-call instrumentation gap in Figure 8 is a serious correctness issue, but it appears fixable by adding a shadow-stack store and updating the associated text, so I recommend major revision rather than rejection. I would encourage the authors to verify their released instrumenter against a regression test that exercises a function-pointer call, since the current description suggests the instrumented code would reset on such a call. The novelty claim of being the first RoT enforcing CFI on low-end devices depends on the completeness of the related-work table; a more systematic comparison would strengthen the paper."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The real news here is architectural: EILID is the first design I know of that puts an active hardware root of trust (CASU) together with a secure shadow stack and compile-time instrumentation for a 16-bit core with no MPU/MMU/TEE. That combination is genuinely new relative to the cited CFA and embedded-CFI literature, and the evaluation is honest and useful. The overhead numbers are believable: ~7.5% runtime, ~10% binary size, modest LUT/register costs because the hardware is mostly CASU. The three-pass compile with address correction is a nice practical detail, and the direct-call and ISR paths are clearly described. The paper is well worth a serious referee.\n\nThe soft spot is real and load-bearing. Section IV-A promises that before each function call site the return address is pushed onto the shadow stack. Figure 8, the only indirect-call instrumentation shown, inserts only a forward-edge table check (NS_EILID_check_ind) and no shadow-stack store before call r13. Since the MSP430 CALL pushes the return address only onto the main stack, the callee's instrumented RET will pop stale data from the shadow stack for any legitimate indirect call, causing a spurious reset, or if the check is skipped, leaving the backward edge unprotected. This is exactly the invariant needed for the headline claim of fine-grained backward-edge integrity. The paper needs to either show the missing store, prove that NS_EILID_check_ind also stores, or correct the design. It is not a drawing nit.\n\nOther soft spots are milder. The instrumenter is 200 lines of Python with no formal proof, and the paper leans on CASU's formal properties without showing that the EILID-specific software/hardware boundary preserves them. The address-shift correction in Section V-A is plausible but not proved for arbitrary instruction sizes. The \"first\" claim is as strong as the comparison table, which is reasonable but mostly against higher-end or attestation-only work. The anonymous repository link needs a commit hash and a checked artifact before this is stable.\n\nBottom line: the central idea is new and the implementation is a solid engineering effort, but the indirect-call gap has to be fixed or explicitly explained before the security claim is credible. I would send it to peer review with a request to address Figure 8, and I would expect a conditional acceptance after that. It deserves referee time.","headline":"A practical CASU-based CFI design for 16-bit MCUs that mostly delivers, but Figure 8 leaves the indirect-call shadow-stack push implicit, which puts the headline backward-edge claim on shaky ground.","tokens_in":687,"tokens_out":1035,"would_cite":true,"duration_ms":29812,"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":"EILID is a root-of-trust architecture that enforces fine-grained backward-edge and function-level forward-edge control-flow integrity on low-end IoT devices, resetting the device on any violation.","keywords":["control-flow integrity","shadow stack","low-end IoT devices","root of trust","compile-time instrumentation","runtime monitoring","embedded systems security","return address protection"],"falsifier":"Inspect the instrumented assembly produced for a 16-bit MCU program that uses an indirect function call. If the instrumentation before the indirect-call instruction contains only a function-address check and no shadow-stack store of the return address (as in the paper's Figure 8), then the callee's return check will pop an entry that was never pushed; a single indirect call desynchronizes the shadow stack, and a corrupted main-stack return address would either reset the device spuriously or pass the check. This outcome is directly observable in the generated binary and in cycle-level simulation.","tokens_in":11290,"feed_emoji":"🛡️","tokens_out":8659,"duration_ms":77328,"temperature":0.7,"pith_summary":"EILID is a hybrid hardware/software architecture that gives low-end IoT microcontrollers a real-time, prevention-based defense against control-flow attacks. The paper argues that prior solutions either only detect attacks after the fact or require resources that small bare-metal microcontrollers do not have. EILID instead instruments the device software at compile time so that every function call, return, interrupt entry and exit, and indirect call is checked against a secure shadow stack maintained by trusted software in ROM; on any mismatch, the hardware resets the device. This makes EILID, on the paper's account, the first active root of trust that enforces control-flow integrity on low-end devices, with an average runtime overhead around 7.5% across seven applications.","feed_headline":"EILID: chip-level guard resets IoT devices on control-flow violation","feed_subtitle":"Fine-grained call and return checks protect tiny bare-metal MCUs at roughly seven percent runtime overhead.","key_machinery":"The load-bearing mechanism is a secure shadow stack paired with semi-automatic compile-time instrumentation. The instrumenter rewrites assembly so that before each function call the return address is pushed onto the shadow stack through a monitor entry, and before each return the current return address is popped and compared; interrupt prologues and epilogues get analogous calls, and indirect call sites get a function-entry-table lookup before the call. The trusted monitor runs in a secure state in ROM and is the only software allowed to touch the shadow stack, while the hardware resets the device if any validation fails or if the secure-state transition is violated. That combination is what gives EILID its real-time, prevention-based property: a violation is stopped in place rather than reported to a remote verifier.","core_discovery":"On its own terms, EILID's central claim is that usable, real-time control-flow integrity is achievable on low-end, bare-metal MCUs without an MMU, MPU, or trusted execution environment. The design combines a compile-time code instrumenter, a small trusted monitor in secure ROM, and a minimally modified hardware root of trust that resets the chip on any CFI validation failure. It protects function return addresses, interrupt-return contexts, and the targets of indirect function calls, and stores the shadow stack in secure data memory accessible only to the trusted monitor. The paper positions this as the first prevention-based, real-time CFI root of trust for low-end devices, as opposed to attestation schemes that detect but do not stop attacks and CFI designs aimed at resource-rich platforms.","pith_inferences":["A reset-as-policy design trades diagnosis for fail-stop behavior: after a reset the device is clean but the owner learns only that a violation occurred, not which edge or attack it was; a small on-device log or attestation extension would be a natural follow-on.","Since the instrumenter is told to compile out indirect jumps, any hand-written assembly or future compiler feature that emits a computed jump or jump table would fall outside the guaranteed property; verifying this invariant in the toolchain is an implicit burden.","The per-call monitor overhead suggests that extremely hot call sites in hard real-time loops could exceed deadlines; a hardware shadow-stack push or selective instrumentation would be a testable optimization the paper does not explore.","The same instrumented edges and shadow-stack layout could double as a source for on-demand control-flow attestation, giving a device both active prevention and remote forensic visibility from one instrumentation pass."],"forward_implications":["Return-address overwrites and interrupt-context tampering on low-end MCUs become detectable-and-fatal events, since any mismatch triggers an immediate reset rather than continued execution.","Attacks that redirect an indirect call are limited to legitimate function entry addresses, shrinking available code-reuse targets to the device's own function set.","Because the defense runs entirely on the device, safety-critical or time-critical tasks do not need to wait for a remote verifier before a compromised device is neutralized.","The measured overhead range (roughly 2.6% to 13.2% runtime, up to about 21.5% binary growth) suggests the scheme can fit within tight memory and timing budgets on typical low-end workloads.","The fixed 256-byte default shadow stack supports up to 128 stored return addresses or interrupt contexts, which suits typical embedded call depths but rules out deep or recursive call chains."],"supporting_citations":[{"why":"Supplies the active hardware root of trust that EILID reuses for software immutability and reset-on-violation behavior.","marker":"[1]"},{"why":"Provides the open-source 16-bit MCU core used for the prototype, synthesis, and FPGA-based evaluation.","marker":"[60]"},{"why":"Gives a same-platform control-flow attestation baseline whose hardware overhead EILID compares against.","marker":"[23]"},{"why":"Gives an active attestation baseline on the same platform, used to argue EILID's hardware cost is minimal.","marker":"[24]"},{"why":"Represents a hardware CFI design for higher-end platforms that EILID contrasts with to motivate its low-end focus.","marker":"[37]"},{"why":"Represents another hardware-enforced CFI design used as a comparison point in the hardware overhead discussion.","marker":"[38]"},{"why":"Shows a hardware CFA scheme whose large RAM requirement is cited to demonstrate that prior techniques do not fit low-end MCUs.","marker":"[25]"}],"fun_headline_variants":["EILID: chip resets on control-flow violation","Real-time CFI for low-end IoT via hybrid root of trust","EILID: active CFI for tiny MCUs at 7% overhead","No MMU? EILID still enforces fine-grained CFI","EILID: shadow stack and reset guard for bare-metal IoT"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire defense depends on the compile-time instrumenter correctly inserting a matching shadow-stack push and pop at every function call and return, including indirect calls; a missed or mismatched edge lets an attacker redirect control flow without the monitor noticing.","fun_headline_variants_meta":{"raw":{"variants":["EILID: chip resets on control-flow violation","Real-time CFI for low-end IoT via hybrid root of trust","EILID: active CFI for tiny MCUs at 7% overhead","No MMU? EILID still enforces fine-grained CFI","EILID: shadow stack and reset guard for bare-metal IoT"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000498,"raw_usage":{"total_tokens":2411,"prompt_tokens":888,"completion_tokens":1523,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":504,"completion_tokens_details":{"reasoning_tokens":1430}},"tokens_in":504,"tokens_out":1523,"duration_ms":11140,"temperature":1.0,"reasoning_tokens":1430,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T20:10:51.298045+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Inspect the instrumented assembly produced for a 16-bit MCU program that uses an indirect function call. If the instrumentation before the indirect-call instruction contains only a function-address check and no shadow-stack store of the return address (as in the paper's Figure 8), then the callee's return check will pop an entry that was never pushed; a single indirect call desynchronizes the shadow stack, and a corrupted main-stack return address would either reset the device spuriously or pass the check. This outcome is directly observable in the generated binary and in cycle-level simulation.","supporting_citations":[{"cited_title":"CASU: Compromise avoidance via secure update for low-end embedded systems,","cited_arxiv_id":null,"evidence_quote":"Supplies the active hardware root of trust that EILID reuses for software immutability and reset-on-violation behavior."},{"cited_title":"openMSP430","cited_arxiv_id":null,"evidence_quote":"Provides the open-source 16-bit MCU core used for the prototype, synthesis, and FPGA-based evaluation."},{"cited_title":"Tiny-CFA: Minimalistic control-flow attes- tation using verified proofs of execution,","cited_arxiv_id":null,"evidence_quote":"Gives a same-platform control-flow attestation baseline whose hardware overhead EILID compares against."},{"cited_title":"ACFA: Secure runtime auditing & guaranteed device healing via active control flow attestation,","cited_arxiv_id":null,"evidence_quote":"Gives an active attestation baseline on the same platform, used to argue EILID's hardware cost is minimal."},{"cited_title":"HAFIX: Hardware-assisted flow integrity extension,","cited_arxiv_id":null,"evidence_quote":"Represents a hardware CFI design for higher-end platforms that EILID contrasts with to motivate its low-end focus."},{"cited_title":"HCFI: Hardware-enforced control-flow integrity,","cited_arxiv_id":null,"evidence_quote":"Represents another hardware-enforced CFI design used as a comparison point in the hardware overhead discussion."},{"cited_title":"LO-FAT: Low-overhead control flow attestation in hardware,","cited_arxiv_id":null,"evidence_quote":"Shows a hardware CFA scheme whose large RAM requirement is cited to demonstrate that prior techniques do not fit low-end MCUs."}],"review_version":1}