Pith. sign in

REVIEW 3 major objections 6 minor 65 references

EILID: Execution Integrity for Low-end IoT Devices

T0 review · 3 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 2501.09216 v1 pith:O6EF54BM submitted 2025-01-16 cs.CR

Sashidhar Jakkamsetti , Youngil Kim , Andrew Searles , Gene Tsudik This is my paper · ORCID
classification cs.CR
keywords control-flowintegrityshadowstacklow-endIoTdevicesrootoftrustcompile-timeinstrumentationruntimemonitoringembeddedsystemssecurityreturnaddressprotection
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

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.

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 (3)
  1. [Section IV-A and Figure 8] 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.
  2. [Section V-A] 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.
  3. [Section IV-B and V-B] 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.
minor comments (6)
  1. [Table I] The platform is listed as "opemMSP430"; it should be "openMSP430".
  2. [Figures 5 and 6] 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.
  3. [Section III-A] 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.
  4. [Section VI] 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.
  5. [Table III and Section V-B] 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.
  6. [Section IV] The text refers to "Figure II shows instruction sets", but the instruction-set summary is Table II; the cross-reference should be corrected.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: EILID composes CASU hardware with independently specified instrumentation and shadow-stack checks; no prediction reduces to a fit or self-definition.

full rationale

After walking the derivation chain, no circular step is present. EILID's central claim is that compile-time instrumentation (EILIDinst), a trusted shadow-stack monitor (EILIDsw), and CASU-derived hardware (EILIDhw) together enforce backward-edge and function-level forward-edge CFI. The design does not fit a parameter to an output and then call that output a prediction; shadow-stack stores/checks and forward-edge table lookups are constructive mechanisms with independent specifications (Figures 3-9, Section IV). The only external support, CASU [1], is prior published work, and invoking it as a hardware foundation is composition rather than circularity; CASU is not used to prove EILID's own CFI property. The stated limitations (non-control-data attacks, indirect jumps, recursion, Section VII) are scoping restrictions, not reductions of the core claim to its inputs. The reviewer-flagged omission of an explicit shadow-stack store for indirect calls in Fig. 8 is a potential soundness bug, but a correctness gap is not a circularity pattern under the rubric.

Assumptions & free parameters 2 free parameters · 5 assumptions · 1 invented entities

The central claim rests on CASU's hardware guarantees, the security of the shadow-stack memory region, and the correctness of the compile-time instrumenter. None of these are proved in this paper, although the scope limitations (no recursion, no non-control-data attacks) are explicitly documented by the authors.

free parameters (2)
  • shadow_stack_size = 256 bytes (128 return-address entries)
    Chosen by hand as a configurable constant in Section V. If call depth or nested interrupts exceed it, valid programs reset; the paper does not analyze worst-case depth.
  • reserved_registers = r4-r7 (4 of 16 registers)
    Reserved for EILID argument passing (Table III). If application software uses these registers, extra push/pop instructions are required; the added cost is not quantified.
assumptions (5)
  • domain assumption CASU hardware enforces run-time software immutability, atomic secure-state transitions, and reset on violation
    EILID reuses CASU without hardware modification (Section III-A); if CASU's guarantees fail, EILID's reset-on-violation mechanism is unsupported.
  • domain assumption The shadow stack is accessible only to EILIDsw and is not writable by instrumented application code
    Stated in Section III-A; no proof or hardware access-control detail is given beyond the CASU-based secure memory extension.
  • ad hoc to paper EILIDinst correctly instruments every call, return, ISR prologue/epilogue, and indirect call site so shadow-stack pushes and pops match
    The three-pass compile process in Fig. 2 corrects shifted addresses, but no correctness proof is provided and Fig. 8 does not make the store at indirect call sites explicit.
  • domain assumption The compiler/ABI stack layout is the assumed one: return address at r1, interrupt context at 0(r1) and -2(r1)
    Instrumentation code in Figs. 4-6 hardcodes these offsets; a different ABI would break the checks.
  • domain assumption Recursion and non-control-data attacks are out of scope
    Section VII states EILID does not handle recursion or non-control-data attacks; both limitations are documented by the authors.
invented entities (1)
  • Protected shadow stack memory region
    purpose: Stores return addresses and interrupt context outside the reach of non-secure software
    Introduced as a secure DMEM extension of CASU; no independent measurement or external validation is provided in the paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of EILID: Execution Integrity for Low-end IoT Devices." pith.science (2026). https://pith.science/paper/O6EF54BM

@misc{pith2026250109216,
  author       = {Pith},
  title        = {Pith review of: EILID: Execution Integrity for Low-end IoT Devices},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/O6EF54BM}},
  note         = {Machine review of arXiv:2501.09216}
}
read the original abstract

Prior research yielded many techniques to mitigate software compromise for low-end Internet of Things (IoT) devices. Some of them detect software modifications via remote attestation and similar services, while others preventatively ensure software (static) integrity. However, achieving run-time (dynamic) security, e.g., control-flow integrity (CFI), remains a challenge. Control-flow attestation (CFA) is one approach that minimizes the burden on devices. However, CFA is not a real-time countermeasure against run-time attacks since it requires communication with a verifying entity. This poses significant risks if safety- or time-critical tasks have memory vulnerabilities. To address this issue, we construct EILID - a hybrid architecture that ensures software execution integrity by actively monitoring control-flow violations on low-end devices. EILID is built atop CASU, a prevention-based (i.e., active) hybrid Root-of-Trust (RoT) that guarantees software immutability. EILID achieves fine-grained backward-edge and function-level forward-edge CFI via semi-automatic code instrumentation and a secure shadow stack.

Figures

Figures reproduced from arXiv: 2501.09216 by the authors.

Figure 1
Figure 1. EILID Design Overview CF I. Nonetheless, since all prior techniques are geared for higher-end devices, they are not applicable to “bare-metal” devices that we target. Another line of research [22]–[33] focuses on CF A using RA. CF A records a log of the control-flow path taken by the software (on Prv). Upon receiving CF A request from Vrf, Prv generates an unforgeable integrity proof of this log and returns it to Vr… view at source ↗
Figure 2
Figure 2. shows the iterated compile process with EILIDinst. It takes as input two files: (1) *.lst to discover function return addresses, and (2) *.s to be instrumented. Its output is *instr.s file, which is colored red in the iterations. Three iterations are needed due to the input file *.lst, generated after the build is completed, and shifted addresses in the second app_1.s app.c 1st build app_1.o app_1.elf app_1.lst app_… view at source ↗
Figure 5
Figure 5. Instrumentation at ISR Entry point 1 ISR: 2 ... 3 4 5 6 reti (a) Original 1 ISR: 2 ... 3 mov 0(r1), r6 4 mov -2(r1), r7 5 call #NS_EILID_check_rfi 6 reti (b) Instrumented [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figures from the paper (2 more)
Figure 7
Figure 7. Figure 7: Instrumentation at Main Function Entry point [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]
Figure 9
Figure 9. Figure 9: EILID Software Implementation EILID HAFIXHCFI Tiny-CFA ACFA LO-FAT LiteHAX 0 1000 2000 3000 4000 5000 Number of Additional LUTs CFI CFA OpenMSP430 Leon3 SPARC V8 Leon3 SPARC V8 OpenMSP430 OpenMSP430 Pulpino Pulpino Original OpenMSP430 (a) EILID LUT overhead EILID HAFIX…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

65 extracted references · 65 canonical work pages

  1. [1]

    CASU: Compromise avoidance via secure update for low-end embedded systems,

    I. De Oliveira Nunes et al. , “CASU: Compromise avoidance via secure update for low-end embedded systems,” ICCAD, 2022

    work page 2022

  2. [2]

    Number of IoT devices (2023-2030),

    F. Duarte, “Number of IoT devices (2023-2030),” Feb 2023

    work page 2023

  3. [3]

    Security attacks in IoT: A survey,

    J. Deogirikar et al. , “Security attacks in IoT: A survey,” I-SMAC, 2017

    work page 2017

  4. [4]

    Internet of things (IoT): Taxonomy of security attacks,

    M.Nawir et al., “Internet of things (IoT): Taxonomy of security attacks,” ICED, 2016

    work page 2016

  5. [5]

    IoT: Internet of threats? A survey of practical security vulnerabilities in real IoT devices,

    F. Meneghello et al. , “IoT: Internet of threats? A survey of practical security vulnerabilities in real IoT devices,” IEEE IoT-J, 2019

    work page 2019

  6. [6]

    Extended functionality attacks on IoT devices: The case of smart lights,

    E. Ronen and A. Shamir, “Extended functionality attacks on IoT devices: The case of smart lights,” EuroS&P, 2016

    work page 2016

  7. [7]

    A survey on sensor-based threats and attacks to smart devices and applications,

    A. K. Sikder et al., “A survey on sensor-based threats and attacks to smart devices and applications,” IEEE Commun. Surv. Tutor ., 2021

    work page 2021

  8. [8]

    PISTIS: Trusted computing architecture for low-end embedded systems,

    M. Grisafi et al. , “PISTIS: Trusted computing architecture for low-end embedded systems,” USENIX’Sec, 2022

    work page 2022

Show all 65 references
  1. [9]

    Sancus 2.0: A Low-Cost Security Architecture for IoT Devices,

    J. Noorman et al. , “Sancus 2.0: A Low-Cost Security Architecture for IoT Devices,” TOPS, 2017

    2017

  2. [10]

    VRASED: A verified hardware/software co-design for remote attestation,

    I. De Oliveira Nunes et al. , “VRASED: A verified hardware/software co-design for remote attestation,” USENIX’Sec, 2019

    2019

  3. [11]

    On the TOCTOU problem in remote attestation,

    I. De Oliveira Nunes et al. , “On the TOCTOU problem in remote attestation,” CCS, 2021

    2021

  4. [12]

    IDA: Hybrid Attestation with Support for Inter- rupts and TOCTOU,

    F. Arkannezhad et al. , “IDA: Hybrid Attestation with Support for Inter- rupts and TOCTOU,” NDSS, 2024

    2024

  5. [13]

    PURE: Using verified remote attestation to obtain proofs of update, reset and erasure in low-end embedded systems,

    I. De Oliveira Nunes et al. , “PURE: Using verified remote attestation to obtain proofs of update, reset and erasure in low-end embedded systems,” ICCAD, 2019

    2019

  6. [14]

    ASSURED: Architecture for secure software update of realistic embedded devices,

    N. Asokan et al. , “ASSURED: Architecture for secure software update of realistic embedded devices,” TCAD, 2018

    2018

  7. [15]

    Realswatt: Remote software-based attestation for embedded devices under realtime constraints,

    S. Surminski et al. , “Realswatt: Remote software-based attestation for embedded devices under realtime constraints,” CCS, 2021

    2021

  8. [16]

    The Lazarus Effect: Healing compromised devices in the Internet of Small Things,

    M. Huber et al. , “The Lazarus Effect: Healing compromised devices in the Internet of Small Things,” AsiaCCS, 2020

    2020

  9. [17]

    GAROTA: generalized active root-of-trust architecture,

    E. Aliaj et al. , “GAROTA: generalized active root-of-trust architecture,” USENIX’Sec, 2022

    2022

  10. [18]

    Dominance as a New Trusted Computing Primitive for the Internet of Things,

    M. Xu et al., “Dominance as a New Trusted Computing Primitive for the Internet of Things,” S&P, 2019

    2019

  11. [19]

    Understanding IoT security from a market-scale perspec- tive,

    X. Jin et al. , “Understanding IoT security from a market-scale perspec- tive,” 2022

    2022

  12. [20]

    Analyzing and detecting emerging Internet of Things malware: A graph-based approach,

    H. Alasmary et al., “Analyzing and detecting emerging Internet of Things malware: A graph-based approach,” IEEE IoT-J, 2019

    2019

  13. [21]

    SWMAT: Mel-frequency cepstral coefficients- based memory fingerprinting for IoT devices,

    R. Vijayakanthan et al. , “SWMAT: Mel-frequency cepstral coefficients- based memory fingerprinting for IoT devices,” Computers & Security , 2023

    2023

  14. [22]

    C-FLAT: control-flow attestation for embedded systems software,

    T. Abera et al., “C-FLAT: control-flow attestation for embedded systems software,” CCS, 2016

    2016

  15. [23]

    Tiny-CFA: Minimalistic control-flow attes- tation using verified proofs of execution,

    I. De Oliveira Nunes et al. , “Tiny-CFA: Minimalistic control-flow attes- tation using verified proofs of execution,” DATE, 2021

    2021

  16. [24]

    ACFA: Secure runtime auditing & guaranteed device healing via active control flow attestation,

    A. Caulfield et al., “ACFA: Secure runtime auditing & guaranteed device healing via active control flow attestation,” USENIX’Sec, 2023

    2023

  17. [25]

    LO-FAT: Low-overhead control flow attestation in hardware,

    G. Dessouky et al. , “LO-FAT: Low-overhead control flow attestation in hardware,” DAC, 2017

    2017

  18. [26]

    On bridging the gap between control flow integrity and attestation schemes,

    M. Ammar et al. , “On bridging the gap between control flow integrity and attestation schemes,” USENIX’Sec, 2024

    2024

  19. [27]

    Whole-program control-flow path attesta- tion,

    N. Yadav and V . Ganapathy, “Whole-program control-flow path attesta- tion,” CCS, 2023

    2023

  20. [28]

    Recfa: Resilient control-flow attestation,

    Y . Zhang et al., “Recfa: Resilient control-flow attestation,” ACSAC, 2021

    2021

  21. [29]

    ISC-FLAT: On the conflict between control flow attestation and real-time operations,

    A. J. Neto and I. D. O. Nunes, “ISC-FLAT: On the conflict between control flow attestation and real-time operations,” RTAS, 2023

    2023

  22. [30]

    Atrium: Runtime attestation resilient under memory attacks,

    S. Zeitouni et al. , “Atrium: Runtime attestation resilient under memory attacks,” ICCAD, 2017

    2017

  23. [31]

    ZEKRA: Zero-knowledge control-flow attestation,

    H. B. Debes et al. , “ZEKRA: Zero-knowledge control-flow attestation,” AsiaCCS, 2023

    2023

  24. [32]

    ARI: Attestation of real-time mission execution integrity,

    J. Wang et al., “ARI: Attestation of real-time mission execution integrity,” USENIX’Sec, 2023

    2023

  25. [33]

    LiteHAX: lightweight hardware-assisted attestation of program execution,

    G. Dessouky et al. , “LiteHAX: lightweight hardware-assisted attestation of program execution,” ICCAD, 2018

    2018

  26. [34]

    DIALED: Data integrity attestation for low- end embedded devices,

    I. De Oliveira Nunes et al., “DIALED: Data integrity attestation for low- end embedded devices,” DAC, 2021

    2021

  27. [35]

    DIAT: Data integrity attestation for resilient collaboration of autonomous systems.,

    T. Abera et al., “DIAT: Data integrity attestation for resilient collaboration of autonomous systems.,” NDSS, 2019

    2019

  28. [36]

    DO-RA: data-oriented runtime attestation for IoT devices,

    B. Kuang et al. , “DO-RA: data-oriented runtime attestation for IoT devices,” Computers & Security , 2020

    2020

  29. [37]

    HAFIX: Hardware-assisted flow integrity extension,

    L. Davi et al. , “HAFIX: Hardware-assisted flow integrity extension,” DAC, 2015

    2015

  30. [38]

    HCFI: Hardware-enforced control-flow integrity,

    N. Christoulakis et al., “HCFI: Hardware-enforced control-flow integrity,” CODASPY, 2016

    2016

  31. [39]

    FIXER: Flow integrity extensions for embedded risc-v,

    A. De et al. , “FIXER: Flow integrity extensions for embedded risc-v,” DATE, 2019

    2019

  32. [40]

    Silhouette: Efficient protected shadow stacks for embed- ded systems,

    J. Zhou et al. , “Silhouette: Efficient protected shadow stacks for embed- ded systems,” USENIX’Sec, 2020

    2020

  33. [41]

    CFI CaRE: Hardware-supported call and return en- forcement for commercial microcontrollers,

    T. Nyman et al. , “CFI CaRE: Hardware-supported call and return en- forcement for commercial microcontrollers,” RAID, 2017

    2017

  34. [42]

    Strategy without tactics: Policy-agnostic hardware- enhanced control-flow integrity,

    D. Sullivan et al. , “Strategy without tactics: Policy-agnostic hardware- enhanced control-flow integrity,” Proceedings of the 53rd Annual Design Automation Conference, 2016

    2016

  35. [43]

    µRAI: Securing embedded systems with return address integrity,

    N. Almakhdhub et al. , “ µRAI: Securing embedded systems with return address integrity,” NDSS, 2020

    2020

  36. [44]

    A fine-grained control flow integrity approach against runtime memory attacks for embedded systems,

    S. Das et al. , “A fine-grained control flow integrity approach against runtime memory attacks for embedded systems,” VLSI Systems , 2016

    2016

  37. [45]

    PAC it up: Towards pointer integrity using ARM pointer authentication,

    H. Liljestrand et al. , “PAC it up: Towards pointer integrity using ARM pointer authentication,” USENIX’Sec, 2019

    2019

  38. [46]

    Control flow and pointer integrity enforcement in a secure tagged architecture,

    R. T. Gollapudi et al. , “Control flow and pointer integrity enforcement in a secure tagged architecture,” S&P, 2023

    2023

  39. [47]

    Bratter: An instruction set extension for forward control- flow integrity in RISC-V,

    S. Park et al. , “Bratter: An instruction set extension for forward control- flow integrity in RISC-V,” Sensors, 2022

    2022

  40. [48]

    In-Kernel Control-Flow integrity on commodity OSes using ARM pointer authentication,

    S. Yoo et al., “In-Kernel Control-Flow integrity on commodity OSes using ARM pointer authentication,” USENIX’Sec, 2022

    2022

  41. [49]

    seL4: from general purpose to a proof of information flow enforcement,

    T. Murray et al. , “seL4: from general purpose to a proof of information flow enforcement,” S&P, 2013

    2013

  42. [50]

    SOFIA: Software and control flow integrity architecture,

    R. De Clercq et al. , “SOFIA: Software and control flow integrity architecture,” Computers & Security , 2017

    2017

  43. [51]

    Control-flow integrity for real-time embedded sys- tems,

    R. J. Walls et al. , “Control-flow integrity for real-time embedded sys- tems,” ECRTS, 2019

    2019

  44. [52]

    FH-CFI: Fine-grained hardware-assisted control flow integrity for ARM-based IoT devices,

    A. Fu et al. , “FH-CFI: Fine-grained hardware-assisted control flow integrity for ARM-based IoT devices,” Computers & Security , 2022

    2022

  45. [53]

    CEFI: Command execution flow integrity for embedded devices,

    A. Peng et al. , “CEFI: Command execution flow integrity for embedded devices,” DIMVA, 2023

    2023

  46. [54]

    EILID source code

    Anonymous, “EILID source code.” https://anonymous.4open.science/r/ eilid, 2023

    2023

  47. [55]

    The geometry of innocent flesh on the bone: Return-into- libc without function calls (on the x86),

    H. Shacham, “The geometry of innocent flesh on the bone: Return-into- libc without function calls (on the x86),” CCS, 2007

    2007

  48. [56]

    Typro: Forward CFI for C-style indirect function calls using type propagation,

    M. Bauer and other, “Typro: Forward CFI for C-style indirect function calls using type propagation,” ACSAC, 2022

    2022

  49. [57]

    Griffin: Guarding control flows using intel processor trace,

    X. Ge et al., “Griffin: Guarding control flows using intel processor trace,” ACM SIGPLAN Notices , 2017

    2017

  50. [58]

    CCFI: Cryptographically enforced control flow integrity,

    A. J. Mashtizadeh et al., “CCFI: Cryptographically enforced control flow integrity,” CCS, 2015

    2015

  51. [59]

    Enforcing Forward-Edge Control-Flow integrity in GCC & LLVM,

    C. Tice et al. , “Enforcing Forward-Edge Control-Flow integrity in GCC & LLVM,” USENIX’Sec, 2014

    2014

  52. [60]

    openMSP430

    O. Girard, “openMSP430.” https://opencores.org/projects/openmsp430, 2009

    2009

  53. [61]

    APEX: A verified architecture for proofs of execution on remote devices under full software compromise,

    I. De Oliveira Nunes et al. , “APEX: A verified architecture for proofs of execution on remote devices under full software compromise,” USENIX’Sec, 2020

    2020

  54. [62]

    Non-control-data attacks are realistic threats.,

    S. Chen et al. , “Non-control-data attacks are realistic threats.,” USENIX’Sec, 2005

    2005

  55. [63]

    Where does it go? refining indirect-call targets with multi-layer type analysis,

    K. Lu and H. Hu, “Where does it go? refining indirect-call targets with multi-layer type analysis,” CCS, 2019

    2019

  56. [64]

    Fine-grained control-flow integrity for kernel software,

    X. Ge et al. , “Fine-grained control-flow integrity for kernel software,” EuroS&P, 2016

    2016

  57. [65]

    JumpSwitches: Restoring the performance of indirect branches in the era of spectre,

    N. Amit et al. , “JumpSwitches: Restoring the performance of indirect branches in the era of spectre,” USENIX ATC, 2019

    2019

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.