Pith. sign in

REVIEW 4 major objections 6 minor 60 references

RunPBA claims that a PACBTI fault on a Cortex-M microcontroller can be turned into a signed, persistent 'NSPE Compromised' attestation state, at roughly 1-5% overhead.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-03 16:34 UTC pith:XQLHDZSA

load-bearing objection RunPBA is a plausible first PACBTI-based runtime attestation design with an encouraging FVP test, but the headline overhead numbers are PACBTI-only measurements and the fault-discrimination heuristic is untested. the 4 major comments →

arxiv 2512.12729 v1 pith:XQLHDZSA submitted 2025-12-14 cs.CR

RunPBA -- Runtime attestation for microcontrollers with PACBTI

Andr\'e Cirne , Patr\'icia R. Sousa , Jo\~ao S. Resende , Lu\'is Antunes This is my paper
classification cs.CR
keywords runtime attestationcontrol-flow integrityPACBTIARM Cortex-MTrustZoneTrusted Firmware-Membedded securityTOCTOU
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper tries to establish that the Arm PACBTI extension, already present in off-the-shelf Cortex-M85/M52 chips, can carry a runtime attestation system that detects control-flow attacks as they occur. RunPBA runs inside the TrustZone secure environment and configures the processor so that any PAC or BTI violation in the non-secure world escalates into a secure fault; a secure partition then logs the fault, halts the non-secure world, and makes every later attestation token report the device as compromised until it is recovered. The claimed payoff is continuous, TOCTOU-resistant attestation on commodity hardware with no custom silicon, at a geometric-mean overhead of about 1% (CoreMark-Pro) and 4.7% (BEEBS), with similar energy and modest code-size increases. A sympathetic reader would care because this is the first use of PACBTI for runtime attestation, and if it holds up, it gives low-end embedded devices a practical, low-cost way to prove they have not been hijacked.

Core claim

The central claim is that RunPBA can detect attempts at control-flow attack — a PAC verification failure or a BTI landing-pad violation in the non-secure processing environment (NSPE) — and express them during attestation. The design forces every PACBTI failure to escalate from a non-secure UsageFault into a secure HardFault (by disabling the non-secure UsageFault handler and setting the BFHFNMINS escalation bit); the hard fault handler then invokes a secure-partition FLIH that copies the fault context, triggers a SLIH (via a GPIO interrupt) that persists the record in internal trusted storage, and redirects the NSPE's program counter into an infinite loop so it never resumes. The RunPBA par

What carries the argument

The load-bearing mechanism is the PACBTI exception channel: the Armv8.1-M Pointer Authentication and Branch Target Identification extension, which signs return addresses (PAC) and marks legal indirect-branch targets (BTI) and raises a synchronous UsageFault on violation. RunPBA reroutes that fault into the secure world via the Cortex-M escalation configuration (SHCSR_NS.USGFAULTACT cleared, AIRCR.BFHFNMINS set), and a two-level interrupt scheme in the TF-M secure partition manager — a FLIH that captures fault context and a GPIO-linked SLIH that stores it in Internal Trusted Storage — turns the fault into a durable event. The final piece is the attestation token's security-lifecycle claim: it

Load-bearing premise

The entire functional validation runs on an Arm virtual platform simulator because the only real Cortex-M85 board available cannot run Trusted Firmware-M; if the simulator's exception escalation, secure-interrupt dispatch, or GPIO-triggered scheduling differs from real silicon, the detection-and-traceability chain has not actually been demonstrated on hardware.

What would settle it

Run the RunPBA proof-of-concept with the two provided ROP exploits on a real Cortex-M85 board that supports Trusted Firmware-M (or an equivalent secure environment), and check three things: the PAC/BTI violation must escalate into the secure HardFault handler, the NSPE must not resume (the infinite loop must hold), and the next attestation token must carry the NSPE-Compromised flag with the fault record readable from internal trusted storage. A faster negative check: if a FOP-style payload can disable PACBTI and re-enable it before the next attestation request and the token still claims all PA

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • On devices with PACBTI, an attacker who triggers a control-flow violation is halted immediately and the NSPE stays stopped until recovery; the signed attestation token keeps reporting NSPE-Compromised, so a verifier cannot be misled by a TOCTOU gap after the fact.
  • Brute-forcing PAC becomes far less practical because each failed authentication trips the fault path, stops the NSPE, and forces a reboot with a fresh key.
  • The reported overhead (about 1-4.7% time, ~1-4.7% energy, ~5% code size) puts continuous control-flow attestation within reach of energy-constrained, real-time embedded systems.
  • Because RunPBA is implemented as a TF-M Application RoT with minimal core changes, existing TF-M-based products could adopt it by adding a partition, compiler flags, PAC key initialization, and an infinite-loop stub.
  • Fault records in Internal Trusted Storage give incident response a deterministic origin trace for each violation, enabling targeted firmware updates rather than whole-device decommissioning.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The performance numbers measure PACBTI-instrumented code, not the full RunPBA fault path; the paper's inference that the overhead 'would closely mirror' PACBTI alone is sound for steady-state execution, but the fault-path latency (hard fault, FLIH, GPIO-triggered SLIH, ITS write) is untested on silicon and would add delay only when an attack actually occurs.
  • The same escalation-and-claim machinery could be generalized to attest other synchronous hardware faults (for example, MPU violations), if each fault type can be attributed; the claim bits are generic enough to carry additional fault flags.
  • The paper's own TOCTOU caveat suggests a testable hardening: if a privileged FOP gadget can disable and re-enable PACBTI between attestations, the lifecycle claim would show PACBTI disabled during the disabled window — a verifier polling during that window would already see the anomaly, so polling frequency is part of the security argument.
  • Although the authors argue the PACBTI control registers cannot be watched, a compiler change that places BTI landing pads only at genuinely indirect-referenced functions (applying a CFG, as shadow-stack defenses do) would shrink the dispatcher-gadget space and directly reduce the FOP risk they identify.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. RunPBA is a runtime attestation system for ARM Cortex-M microcontrollers that combines the PACBTI extension with Trusted Firmware-M (TF-M). The paper contributes an analysis of PACBTI attack surfaces, a design that converts PAC/BTI faults into secure HardFaults, persists fault context via Internal Trusted Storage, redirects the non-secure processing environment into a loop, and encodes a new 'NSPE Compromised' state in the PSA attestation token's security-lifecycle claim. A proof of concept is evaluated with two ROP exploits on the Arm Corstone-310 FVP, and performance is measured on a Renesas EK-RA8M1 board using BEEBS and CoreMark-Pro, reporting geometric-mean overheads of 4.7% and 1% respectively, with comparable code-size and power increases. The authors provide source code and benchmark artifacts.

Significance. If the design holds up, RunPBA would be a valuable contribution: it is the first system to leverage the on-die PACBTI extension for runtime attestation on Cortex-M, it builds on commodity hardware and existing TF-M infrastructure, and it is evaluated with two concrete exploit payloads and a standard benchmark suite. The paper is transparent about several limitations, including the FVP-only functional validation and the lack of a direct PACBTI-fault discriminator. The availability of code, scripts, and raw measurements is a strength. The main open question is whether the detection and overhead claims survive validation on real silicon and under negative fault cases.

major comments (4)
  1. [Abstract; §6.2] The abstract states that 'RunPBA imposes a geometric mean performance overhead of only 1% and 4.7% across the benchmarks.' The performance evaluation in §6.2, however, measures PACBTI-instrumented binaries running directly on the Renesas EK-RA8M1 without TF-M or any RunPBA component, as the paper acknowledges ('we were unable to directly test our Proof-of-Concept...'). The FVP functional test in §6.1 provides no timing data. The overhead of the complete RunPBA system, including secure-world fault handling, FLIH/SLIH, and attestation token generation, is therefore unmeasured. Please relabel the figures as PACBTI ISA overhead and either measure or explicitly bound the additional RunPBA-specific costs before attributing them to RunPBA.
  2. [§5.4.1; §6.1] The detection guarantee rests on distinguishing PACBTI-triggered UsageFaults from other Invalid State faults, since the NSPE UsageFault handler is disabled and all such faults escalate to the secure HardFault. The text admits 'the current design does not provide a direct mechanism for uniquely identifying PACBTI faults' and relies on two heuristics (stacked PC points to a verification instruction; EPSR.B set). These heuristics are not validated with any negative tests: no benign faults (division by zero, unaligned access, undefined instruction, invalid EXC_RETURN) are injected to measure false positives, and the paper does not specify how 'verification instruction' is decided. A false positive would place a healthy device in NSPE Compromised; a false negative would break the attestation claim. This is a logical gap in the security argument.
  3. [§6.1; refs [44,45]] All functional validation of RunPBA itself is on the Arm Corstone-310 FVP because the only real PACBTI silicon available (Renesas EK-RA8M1) cannot run TF-M. The detection pipeline depends on FVP exception semantics: UsageFault escalation to secure HardFault via BFHFNMINS, SPM FLIH dispatch, and GPIO-triggered SLIH. Section 5.7 itself hedges a race ('there is a small time window'). Since the central claim is detection on a real device, the paper should either validate on a PACBTI-enabled Cortex-M device with a TF-M port or clearly state that the detection claim is simulator-only. Without silicon confirmation, the system may not behave as specified.
  4. [§6.2, Tables 1-2] The geomean overhead figures are computed after removing any benchmark in which the PACBTI build ran faster than baseline (three BEEBS and two CoreMark-Pro tests). This one-sided exclusion biases the reported overhead upward. Moreover, the BEEBS geomean is sensitive to the recursion test: excluding it lowers the figure from 4.7% to 3.7%, as the authors note in §6.2.2. The exclusion criteria should be pre-specified or accompanied by a full distribution and sensitivity analysis. The -O0 compilation also limits the generality of the 'sufficient for real-world deployment' claim; at minimum, results at -Os should be reported.
minor comments (6)
  1. [§5.4.2, Figure 3] The text says the 'first bit' of the security-lifecycle claim indicates a runtime failure, while Figure 3 numbers bits 0–15. Please clarify the bit numbering (LSB vs MSB) and specify whether the implementation-defined bits are the high byte.
  2. [§7] The conclusion expands 'FOP' as 'Fault of Protection', but Section 4 defines it as 'Function Oriented Programming'. Please correct the expansion for consistency.
  3. [§6.2.1] Typo: 'CorMark-Pro' should be 'CoreMark-Pro' in the first sentence of the result analysis.
  4. [Tables 1-2] The metric labeled 'Current over time' is expressed in Amperes; this is a charge/energy measure (A·s), not power. Please correct the label and units.
  5. [§6] The source-code URLs differ between the anonymous review link and the author GitHub link. Please reconcile them so the artifacts are unambiguously accessible.
  6. [§5.7] Minor language issue: 'RUNPBA will loose its visibility' should read 'lose'.

Circularity Check

0 steps flagged

No significant circularity: RunPBA's claims rest on external benchmarks and explicit design choices; the only weaknesses are disclosed extrapolations and unvalidated fault discrimination, not self-equivalent derivations.

full rationale

I examined every load-bearing step in the paper's argument. The detection claim in §1/§5.4 is supported by a concrete mechanism (PACBTI fault → UsageFault → BFHFNMINS escalation to secure HardFault → FLIH/SLIH → ITS → attestation token bit) and by functional tests against two ROP exploits that target PAC and BTI respectively; the verdict 'NSPE Compromised' is not fitted to the exploits, it is a deterministic consequence of the fault-handling path. The performance numbers in §6.2 are measured on external benchmarks (BEEBS, CoreMark-Pro) with external hardware (Renesas EK-RA8M1, PPK2), and the paper openly states that because the board cannot run TF-M, it measured PACBTI-instrumented code and inferred RunPBA's overhead would 'closely mirror' it; this is a disclosed external-validity extrapolation, not a derivation equivalent to its own inputs. The admitted lack of a direct mechanism to uniquely identify PACBTI faults and the heuristic indicators (PC pointing at a verification instruction, EPSR.B) are unvalidated security properties, which is a correctness/verification gap rather than circularity. There are no self-citations, no imported uniqueness theorem, no ansatz smuggled via citation, and no fitted parameter renamed as a prediction. Under the required standard (quote a specific reduction), no circular step can be exhibited.

Axiom & Free-Parameter Ledger

4 free parameters · 5 axioms · 1 invented entities

No fitted physical quantities appear; the ledger's free parameters are benchmark-analysis choices. The load-bearing axioms are the threat model, FVP-as-silicon, the unmeasured RunPBA≃PACBTI overhead equivalence, per-boot key randomization, and the heuristic PACBTI-fault identification. There are no invented physical entities; the only invented ledger entry is the lifecycle state, which has an external verification handle.

free parameters (4)
  • BEEBS geomean inclusion rule = 24 of 30 tests; recursion retained; 3 crashed and 3 faster-with-PACBTI excluded
    Hand-chosen exclusion of six tests (§6.2) materially changes the headline: with recursion removed the geomean drops to 3.7%, and removing faster-than-baseline tests raises the reported overhead (conservative direction).
  • CoreMark-Pro geomean inclusion rule = unspecified number of faster-with-PACBTI tests excluded
    Same exclusion-by-outcome rule applied; the number of excluded tests is not reported, so the 1.1% figure cannot be recomputed from the paper alone.
  • Compiler optimization level = -O0 (LLVM 17.0.1)
    Chosen so function calls are not inlined/removed, maximizing PACBTI instruction count; the paper notes this is why overhead numbers are not representative of optimized builds, where PACBTI impact would be smaller.
  • BEEBS loop count = 1024 iterations
    Chosen to make short tests measurable; a measurement configuration, not a fitted constant.
axioms (5)
  • domain assumption The attacker has arbitrary read/write within NSPE memory (respecting MPU/DEP) but cannot generate PACs, perform non-control data attacks, side-channel or physical attacks, and cannot compromise TF-M.
    Establishes the entire threat model (§5.2); every security claim in §5.7 is relative to it. A PAC-generation-capable attacker or a TF-M bug is out of scope and would break the guarantees.
  • domain assumption The Corstone-310 FVP faithfully reproduces Cortex-M85 exception escalation and PACBTI fault semantics.
    All functional validation of RunPBA itself runs on the FVP (§6.1) because the RA8M1 board lacks TF-M support (§6.2); the UsageFault→HardFault→FLIH→SLIH pipeline is behavior that must match silicon.
  • ad hoc to paper RunPBA's steady-state NSPE overhead equals PACBTI's instruction overhead.
    The paper's §6.2 substitute for an end-to-end measurement: 'any performance overhead introduced by our system would closely mirror the impact of executing PACBTI-instrumented code.' The attribution of 1%/4.7% to RunPBA rests on this unmeasured equivalence.
  • domain assumption The NSPE OS randomizes the PAC key on every boot.
    §5.5/§5.7 rely on fresh keys so brute-force attempts are interrupted by the device reset; if the OS fails to do this, the paper's brute-force mitigation argument weakens (it notes the attestation token would still record the fault).
  • ad hoc to paper PACBTI faults can be distinguished from other Invalid State Usage Faults by examining whether the saved PC points at a PAC/AUT verification instruction or whether EPSR.B is set.
    §5.4.1 admits 'the current design does not provide a direct mechanism for uniquely identifying PACBTI faults' and that division-by-zero also sets Invalid State; the system then relies on this heuristic for fault attribution and traceability, and the heuristic is not empirically evaluated (no false-positive analysis).
invented entities (1)
  • NSPE Compromised lifecycle state independent evidence
    purpose: New state in the PSA device lifecycle entered on a PACBTI fault; represented with two bits of the security lifecycle claim so every attestation token reports whether a runtime control-flow failure was detected (§5.3, §5.4.2).
    A third-party verifier can check the lifecycle claim bit in the signed EAT token, a falsifiable external handle. The bit's correctness, however, depends on the untested fault-identification heuristic.

pith-pipeline@v1.3.0-alltime-deepseek · 23437 in / 22833 out tokens · 191194 ms · 2026-08-03T16:34:11.633273+00:00 · methodology

0 comments
read the original abstract

The widespread adoption of embedded systems has led to their deployment in critical real-world applications, making them attractive targets for malicious actors. These devices face unique challenges in mitigating vulnerabilities due to intrinsic constraints, such as low energy consumption requirements and limited computational resources. This paper presents RunPBA, a hardware-based runtime attestation system designed to defend against control flow attacks while maintaining minimal performance overhead and adhering to strict power consumption constraints. RunPBA leverages PACBTI, a new processor extension tailored for the Arm Cortex M processor family, allowing robust protection without requiring hardware modifications, a limitation present in similar solutions. We implemented a proof-of-concept and evaluated it using two benchmark suites. Experimental results indicate that RunPBA imposes a geometric mean performance overhead of only 1% and 4.7% across the benchmarks, underscoring its efficiency and suitability for real-world deployment.

Figures

Figures reproduced from arXiv: 2512.12729 by Andr\'e Cirne, Jo\~ao S. Resende, Lu\'is Antunes, Patr\'icia R. Sousa.

Figure 1
Figure 1. Figure 1: PSA security lifecycle with RunPBA RunPBA detects a PACBTI fault, it generates an object containing critical debug information that helps pinpoint the fault’s origin, facilitating device recovery after an attack (R4). This tracing capability leverages the isolation features of TF-M, which enforces the separation between NSPE and SPE. RunPBA uses this separation to mitigate attacks on the NSPE, securely sto… view at source ↗
Figure 3
Figure 3. Figure 3: Representation of the Security Lifecycle claim with the RunPBA system in the attestation token device is in the NSPE compromised state. The second bit is set to 1 if a malfunction occurs within the RunPBA system itself, such as when the RunPBA application is unable to access secure storage. The remaining bits represent the status of each PACBTI feature: a value of 0 indicates that a feature is disabled, wh… view at source ↗
Figure 2
Figure 2. Figure 2: PACBTI fault handling with RunPBA 5.4.2. Attestation The PSA Initial Attestation Service is the TrustedFirmware￾M (TFM) application responsible for attesting the device’s identity. This service generates a signed token following the Arm’s PSA Attestation [51] model. In this model, the verifier challenges the attestation service with a nonce that must be contained in the response to verify its freshness. Th… view at source ↗
Figure 4
Figure 4. Figure 4: RunPBA lifecycle overview scheduling the execution of RunPBA 10 11 . The RunPBA application will then store the fault and its origin in a secure way 12 . On the attestation side, the only difference compared to the standard TF-M attestation system is that during the generation of the attestation token, the attestation service Cirne et al.: Preprint submitted to Elsevier Page 9 of 16 [PITH_FULL_IMAGE:figur… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

60 extracted references · 1 canonical work pages

  1. [1]

    Invited-things,trouble,trust,in:Proceedings ofthe53rdAnnualDesignAutomationConference,ACM,NewYork, NY, USA

    Abera, T., Asokan, N., Davi, L., Koushanfar, F., Paverd, A., Sadeghi, A.R.,Tsudik,G.,2016. Invited-things,trouble,trust,in:Proceedings ofthe53rdAnnualDesignAutomationConference,ACM,NewYork, NY, USA. URL: https://doi.org/10.1145/2897937.2905020, doi:10. 1145/2897937.2905020

    arXiv 2016

  2. [2]

    uRAI: Return Address Integrity for Embedded Systems

    Almakhdhub,N.,Clements,A.A.,Bagchi,S.,Payer,M.,2020. uRAI: Return Address Integrity for Embedded Systems. Technical Report. doi:10.14722/ndss.2020.24016

    arXiv 2020

  3. [3]

    On bridging the gap between control flow integrity and attestation schemes, in: 33rd USENIX Security Symposium (USENIX Security 24), pp

    Ammar, M., Abdelraoof, A., Vlasceanu, S., 2024. On bridging the gap between control flow integrity and attestation schemes, in: 33rd USENIX Security Symposium (USENIX Security 24), pp. 6633– 6650

    2024

  4. [4]

    State-of-the-art software-based remote attestation: Opportunities and open issues for internet of things

    Ankergård, S.F.J.J., Dushku, E., Dragoni, N., 2021. State-of-the-art software-based remote attestation: Opportunities and open issues for internet of things. Sensors 21, 1598

    2021

  5. [5]

    Lahel: Lightweight attestation hardening embedded devices using macrocells, in: 2020 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), pp

    Arias, O., Sullivan, D., Shan, H., Jin, Y., 2020. Lahel: Lightweight attestation hardening embedded devices using macrocells, in: 2020 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), pp. 305–315. doi:10.1109/HOST45689.2020.9300257

    arXiv 2020

  6. [6]

    ArmCortex-M85ProcessorTechnicalReference Manual

    ArmLimited,2020. ArmCortex-M85ProcessorTechnicalReference Manual. r1p1 ed. Accessed on May 22, 2024

    2020

  7. [7]

    Platform Security Model

    Arm Limited, 2021. Platform Security Model. Technical Report JSADEN014. Accessed on June 13, 2024

    2021

  8. [8]

    Initialattestationreport-psacertifiedattestation api 1.0

    ArmLimited,2022. Initialattestationreport-psacertifiedattestation api 1.0. https://arm-software.github.io/psa-api/attestation/1.0/ overview/report.html#initial-attestation-report. Accessed: Aug 19, 2024

    2022

  9. [9]

    Pacman security vulnerability

    Arm Limited, 2023. Pacman security vulnerability. https:// developer.arm.com/documentation/ka005109/latest. URL: https:// developer.arm.com/documentation/ka005109/latest. accessed on May 22, 2023

    2023

  10. [10]

    Trusted Firmware-M Documentation

    Arm Limited, 2024. Trusted Firmware-M Documentation. https: //tf-m-user-guide.trustedfirmware.org. Accessed on June 7, 2024

    2024

  11. [11]

    Examining pointer authentication on the iphone xs

    Azad, B., 2019. Examining pointer authentication on the iphone xs. https://googleprojectzero.blogspot. com/2019/02/examining-pointer-authentication-on.html. URL: https://googleprojectzero.blogspot.com/2019/02/ examining-pointer-authentication-on.html. accessed: 2024-05-15

    2019

  12. [12]

    Bletsch, T., Jiang, X., Freeh, V.W., Liang, Z., 2011. Jump-oriented programming: a new class of code-reuse attack, in: Proceedings of the 6th ACM Symposium on Information, Computer and Communi- cations Security, Association for Computing Machinery, New York, NY,USA.p.30–40. URL: https://doi.org/10.1145/1966913.1966919, doi:10.1145/1966913.1966919

    arXiv 2011

  13. [13]

    Control-flow integrity: Precision, security, and performance

    Burow, N., Carr, S.A., Nash, J., Larsen, P., Franz, M., Brunthaler, S., Payer, M., 2017. Control-flow integrity: Precision, security, and performance. ACM Comput. Surv. 50. URL: https://doi.org/10. 1145/3054924, doi:10.1145/3054924

    doi:10.1145/3054924 2017

  14. [14]

    Sok:Shininglightonshadow stacks, in: 2019 IEEE Symposium on Security and Privacy (SP), IEEE

    Burow,N.,Zhang,X.,Payer,M.,2019. Sok:Shininglightonshadow stacks, in: 2019 IEEE Symposium on Security and Privacy (SP), IEEE. pp. 985–999

    2019

  15. [15]

    Sum: Efficient shadow stack protection on arm cortex-m

    Choi, W., Seo, M., Lee, S.,Kang, B.B., 2024. Sum: Efficient shadow stack protection on arm cortex-m. Computers & Security 136, 103568. URL: https://www.sciencedirect.com/science/article/pii/ S0167404823004789, doi:https://doi.org/10.1016/j.cose.2023.103568

    arXiv 2024

  16. [16]

    The performance cost of shadow stacks and stack canaries, in: Proceedings of the 10th ACM Symposium on Information, Computer and Communications Security, pp

    Dang, T.H., Maniatis, P., Wagner, D., 2015. The performance cost of shadow stacks and stack canaries, in: Proceedings of the 10th ACM Symposium on Information, Computer and Communications Security, pp. 555–566

    2015

  17. [17]

    Hafix: Hardware-assisted flow integrity extension, in: Proceedings of the 52nd Annual Design Automation Conference, pp

    Davi,L.,Hanreich,M.,Paul,D.,Sadeghi,A.R.,Koeberl,P.,Sullivan, D., Arias, O., Jin, Y., 2015. Hafix: Hardware-assisted flow integrity extension, in: Proceedings of the 52nd Annual Design Automation Conference, pp. 1–6

    2015

  18. [18]

    Dynamic integrity measurementandattestation:towardsdefenseagainstreturn-oriented programmingattacks,in:Proceedingsofthe2009ACMworkshopon Scalable trusted computing, pp

    Davi, L., Sadeghi, A.R., Winandy, M., 2009. Dynamic integrity measurementandattestation:towardsdefenseagainstreturn-oriented programmingattacks,in:Proceedingsofthe2009ACMworkshopon Scalable trusted computing, pp. 49–54

    2009

  19. [19]

    Camouflage: Hardware-assisted cfi for the arm linux kernel, in: 2020 57th ACM/IEEE Design Automation Conference (DAC), IEEE

    Denis-Courmont, R., Liljestrand, H., Chinea, C., Ekberg, J.E., 2020. Camouflage: Hardware-assisted cfi for the arm linux kernel, in: 2020 57th ACM/IEEE Design Automation Conference (DAC), IEEE. pp. 1–6

    2020

  20. [20]

    Litehax: Lightweight hardware-assisted attestation of program execution, in: ProceedingsoftheInternationalConferenceonComputer-AidedDe- sign, ACM

    Dessouky, G., Abera, T., Ibrahim, A., Sadeghi, A.R., 2018. Litehax: Lightweight hardware-assisted attestation of program execution, in: ProceedingsoftheInternationalConferenceonComputer-AidedDe- sign, ACM. pp. 1–8. doi:10.1145/3240765.3240821

    arXiv 2018

  21. [21]

    Dessouky,G.,Zeitouni,S.,Nyman,T.,Paverd,A.,Davi,L.,Koeberl, P., Asokan, N., Sadeghi, A.R., 2017. Lo-fat: Low-overhead control flow attestation in hardware, in: Proceedings of the 54th Annual Design Automation Conference 2017, Association for Computing Machinery, New York, NY, USA. URL:https://doi.org/10.1145/ 3061639.3062276, doi:10.1145/3061639.3062276

    arXiv 2017

  22. [22]

    Coremark-pro - eembc embedded microprocessor benchmark consortium

    EEMBC, 2024. Coremark-pro - eembc embedded microprocessor benchmark consortium. https://www.eembc.org/coremark-pro/. Ac- cessed: 2024-10-12

    2024

  23. [23]

    Fanti,A.,Perez,C.C.,Denis-Courmont,R.,Roascio,G.,Ekberg,J.E.,

  24. [24]

    Hardware-assisted remote attestation design for critical embedded systems

    Geden, M., Rasmussen, K., 2023. Hardware-assisted remote attestation design for critical embedded systems. IET Information Security 17, 518–533. URL: https: //ietresearch.onlinelibrary.wiley.com/doi/abs/10.1049/ ise2.12113, doi: https://doi.org/10.1049/ise2.12113, arXiv:https://ietresearch.onlinelibrary.wiley.com/doi/pdf/10.1049/ise2.12113

    work page doi:10.1049/ise2.12113 2023

  25. [25]

    Function-oriented programming: A new class of code reuse attack in c applications, in: 2018 IEEE ConferenceonCommunicationsandNetworkSecurity(CNS),IEEE

    Guo, Y., Chen, L., Shi, G., 2018. Function-oriented programming: A new class of code reuse attack in c applications, in: 2018 IEEE ConferenceonCommunicationsandNetworkSecurity(CNS),IEEE. pp. 1–9

    2018

  26. [26]

    Practicalruntime attestation for tiny iot devices, in: NDSS Workshop on Decentralized IoT Security and Standards (DISS)

    Hristozov,S.,Heyszl,J.,Wagner,S.,Sigl,G.,2018. Practicalruntime attestation for tiny iot devices, in: NDSS Workshop on Decentralized IoT Security and Standards (DISS)

    2018

  27. [27]

    Huo, D., Wang, Y., Liu, C., Li, M., Wang, Y., Xu, Z., 2020. Lape: A lightweight attestation of program execution scheme for bare- metalsystems,in:2020IEEE22ndInternationalConferenceonHigh Performance Computing and Communications; IEEE 18th Interna- tional Conference on Smart City; IEEE 6th International Conference on Data Science and Systems (HPCC/SmartCi...

    Pith/arXiv arXiv 2020

  28. [28]

    Tzmcfi: Rtos-awarecontrol-flowintegrityusingtrustzoneforarmv8-m

    Kawada, T., Honda, S., Matsubara, Y., Takada, H., 2020. Tzmcfi: Rtos-awarecontrol-flowintegrityusingtrustzoneforarmv8-m. Inter- national Journal of Parallel Programming 49, 216–236. doi:10.1007/ s10766-020-00673-z

    2020

  29. [29]

    A survey of remote attestation in internet of things: Attacks, countermeasures, and prospects

    Kuang, B., Fu, A., Susilo, W., Yu, S., Gao, Y., 2022. A survey of remote attestation in internet of things: Attacks, countermeasures, and prospects. Computers & Security 112, 102498. URL: https: //www.sciencedirect.com/science/article/pii/S0167404821003229, doi:https://doi.org/10.1016/j.cose.2021.102498

    arXiv 2022

  30. [30]

    Do-ra:Data- orientedruntimeattestationforiotdevices

    Kuang,B.,Fu,A.,Zhou,L.,Susilo,W.,Zhang,Y.,2020. Do-ra:Data- orientedruntimeattestationforiotdevices. Computers&Security97, 101945. URL: https://www.sciencedirect.com/science/article/pii/ S0167404820302212, doi:https://doi.org/10.1016/j.cose.2020.101945

    arXiv 2020

  31. [31]

    Liljestrand, H., Nyman, T., Gunn, L.J., Ekberg, J.E., Asokan, N.,

  32. [32]

    {PAC} it up: Towards pointer integrity using {ARM} pointer authentication, in: 28th USENIX Security Sympo- sium (USENIX Security 19), pp

    Liljestrand, H., Nyman, T., Wang, K., Perez, C.C., Ekberg, J.E., Asokan, N., 2019. {PAC} it up: Towards pointer integrity using {ARM} pointer authentication, in: 28th USENIX Security Sympo- sium (USENIX Security 19), pp. 177–194

    2019

  33. [33]

    Fop mythoclast

    LMS57, 2023. Fop mythoclast. https://github.com/LMS57/FOP_ Mythoclast. Accessed: January 6, 2025

    2023

  34. [34]

    TheEntityAttestationToken(EAT).Internet-Draftdraft-ietf-rats-eat-

    Lundblade, L., Mandyam, G., O’Donoghue, J., Wallace, C., 2024. TheEntityAttestationToken(EAT).Internet-Draftdraft-ietf-rats-eat-

    2024

  35. [35]

    Detecting compromised iotdevices:Existingtechniques,challenges,andawayforward

    Makhdoom, I., Abolhasan, M., Franklin, D., Lipman, J., Zimmer- mann, C., Piccardi, M., Shariati, N., 2023. Detecting compromised iotdevices:Existingtechniques,challenges,andawayforward. Com- puters & Security 132, 103384. URL: https://www.sciencedirect. com/science/article/pii/S0167404823002948,doi: https://doi.org/10. 1016/j.cose.2023.103384

    arXiv 2023

  36. [36]

    Armv8.1-m pointer authentication and branch target identification extension

    Mujumdar, A., 2021. Armv8.1-m pointer authentication and branch target identification extension. URL: https://community.arm.com/ arm-community-blogs/b/architectures-and-processors-blog/posts/ armv8-1-m-pointer-authentication-and-branch-target-identification-extension . Accessed: Apr 23, 2023

    2021

  37. [37]

    work in Progress

    URL: https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ 30/. work in Progress

  38. [38]

    Cfi care: Hardware-supported call and return enforcement for commercial mi- crocontrollers, in: Dacier, M., Bailey, M., Polychronakis, M., An- tonakakis, M

    Nyman, T., Ekberg, J.E., Davi, L., Asokan, N., 2017. Cfi care: Hardware-supported call and return enforcement for commercial mi- crocontrollers, in: Dacier, M., Bailey, M., Polychronakis, M., An- tonakakis, M. (Eds.), Research in Attacks, Intrusions, and Defenses, Springer International Publishing, Cham. pp. 259–284

    2017

  39. [39]

    Security requirements analysis for the iot, in: 2017 International Conference on Platform Technology and Service (PlatCon), IEEE

    Oh, S.R., Kim, Y.G., 2017. Security requirements analysis for the iot, in: 2017 International Conference on Platform Technology and Service (PlatCon), IEEE. pp. 1–6

    2017

  40. [40]

    Protecting indirect branches against fault attacks using arm pointer authentication, in: 2021IEEEInternationalSymposiumonHardwareOrientedSecurity and Trust (HOST), IEEE

    Nasahl, P., Schilling, R., Mangard, S., 2021. Protecting indirect branches against fault attacks using arm pointer authentication, in: 2021IEEEInternationalSymposiumonHardwareOrientedSecurity and Trust (HOST), IEEE. pp. 68–79

    2021

  41. [41]

    Identifying compiler options to minimize energy consumption for embedded platforms

    Pallister, J., Hollis, S.J., Bennett, J., 2015. Identifying compiler options to minimize energy consumption for embedded platforms. The Computer Journal 58, 95–109

    2015

  42. [42]

    Pointer authentication on armv8.3 design and analysis of the new software security instructions

    Qualcomm Technologies, Inc., 2017. Pointer authentication on armv8.3 design and analysis of the new software security instructions. https://www.qualcomm.com/content/dam/ qcomm-martech/dm-assets/documents/pointer-auth-v7.pdf . URL: https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/ documents/pointer-auth-v7.pdf. accessed: 2024-05-16

    2017

  43. [43]

    Beebs: Open benchmarks for energy measurements on embedded platforms

    Pallister, J., Hollis, S., Bennett, J., 2013. Beebs: Open benchmarks for energy measurements on embedded platforms. arXiv preprint arXiv:1308.5174

    Pith/arXiv arXiv 2013

  44. [44]

    Arm trust firmware m on ra8m1 - renesas engineer- ingcommunityforum

    Renesas, 2024a. Arm trust firmware m on ra8m1 - renesas engineer- ingcommunityforum. https://community.renesas.com/mcu-mpu/ra/f/ forum/34852/arm-trust-firmware-m-on-ra8m1 . Accessed:2024-08-19

    2024

  45. [45]

    Request for the latest trusted firmware- m sample project - renesas engineering community forum

    Renesas, 2024b. Request for the latest trusted firmware- m sample project - renesas engineering community forum. https://community.renesas.com/mcu-mpu/ra/f/forum/35029/ request-for-the-latest-trusted-firmware-m-sample-project . Accessed: 2024-08-19

    2024

  46. [46]

    Ravichandran, J., Na, W.T., Lang, J., Yan, M., 2022. Pacman: At- tackingarmpointerauthenticationwithspeculativeexecution,in:Pro- ceedings of the 49th Annual International Symposium on Computer Architecture, Associationfor ComputingMachinery, NewYork, NY, USA. p. 685–698. URL: https://doi.org/10.1145/3470496.3527429, doi:10.1145/3470496.3527429

    arXiv 2022

  47. [47]

    Shacham, H., 2007. The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86), in: Proceedings of the 14th ACM Conference on Computer and Communications Security, Association for Computing Machinery, New York, NY, USA. p. 552–561. URL: https://doi.org/10.1145/1315245.1315313, doi:10.1145/1315245.1315313

    arXiv 2007

  48. [48]

    faslr: Function-based aslr for resource-constrained iot systems, in: Euro- pean Symposium on Research in Computer Security, Springer

    Shao, X., Luo, L., Ling, Z., Yan, H., Wei, Y., Fu, X., 2022. faslr: Function-based aslr for resource-constrained iot systems, in: Euro- pean Symposium on Research in Computer Security, Springer. pp. 531–548

    2022

  49. [49]

    Power profiler kit ii - nordic semicon- ductor

    Semiconductor, N., 2024. Power profiler kit ii - nordic semicon- ductor. https://www.nordicsemi.com/Products/Development-hardware/ Power-Profiler-Kit-2. Accessed: 2024-09-12

    2024

  50. [50]

    Generic threat model

    TrustedFirmware-M Project, . Generic threat model. https://trustedfirmware-m.readthedocs.io/en/latest/security/ threat_models/generic_threat_model.html. Accessed: 2025-03-10

    2025

  51. [51]

    Tschofenig, H., Frost, S., Brossard, M., Shaw, A.L., Fossati, T.,

  52. [52]

    Bypassing modern cpu protections with function-oriented programming

    Stratton, L., Cronin, K., 2023. Bypassing modern cpu protections with function-oriented programming

    2023

  53. [53]

    2761–2778

    Wang, J., Wang, Y., Li, A., Xiao, Y., Zhang, R., Lou, W., Hou, Y.T., Zhang, N., 2023.{ARI}: Attestation of real-time mission execution integrity, in: 32nd USENIX Security Symposium (USENIX Security 23), pp. 2761–2778

    2023

  54. [54]

    Efficientcfienforcement for embedded systems using arm trustzone-m

    Yeo,G.,Kim,Y.,Song,S.,Kwon,D.,2022. Efficientcfienforcement for embedded systems using arm trustzone-m. IEEE Access 10, 132675–132684. doi:10.1109/ACCESS.2022.3230791

    arXiv 2022

  55. [55]

    Zhang, L., Chen, Q., Yan, F., 2021. A security enhanced key managementserviceforarmpointerauthentication,in:AppliedCryp- tography in Computer and Communications: First EAI International Conference,AC32021,VirtualEvent,May15-16,2021,Proceedings 1, Springer. pp. 41–55

    2021

  56. [56]

    Control-flow integrity for real-time embedded systems, in:31stEuromicroConferenceonReal-TimeSystems(ECRTS2019), Schloss-Dagstuhl-Leibniz Zentrum für Informatik

    Walls,R.J.,Brown,N.F.,LeBaron,T.,Shue,C.A.,Okhravi,H.,Ward, B.C., 2019. Control-flow integrity for real-time embedded systems, in:31stEuromicroConferenceonReal-TimeSystems(ECRTS2019), Schloss-Dagstuhl-Leibniz Zentrum für Informatik

    2019

  57. [60]

    Silhouette: Efficient protected shadow stacks for embedded systems, in: 29th USENIX Security Symposium (USENIX Security 20), pp

    Zhou, J., Du, Y., Shen, Z., Ma, L., Criswell, J., Walls, R.J., 2020. Silhouette: Efficient protected shadow stacks for embedded systems, in: 29th USENIX Security Symposium (USENIX Security 20), pp. 1219–1236. A. BTI-enabled compilation During the evaluation phase of RunPBA, we analyzed firmwarecompiledwithdifferentPACBTIsettingsandcom- pilers. Our goal wa...

    2020

  58. [2020]

    URL: https://arxiv

    Pacstack: an authenticated call stack. URL: https://arxiv. Cirne et al.: Preprint submitted to Elsevier Page 15 of 16 RunPBA - Runtime attestation for microcontrollers with PACBTI org/abs/1905.10242, arXiv:1905.10242

    Pith/arXiv arXiv 1905

  59. [2022]

    IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 41, 3757–3766

    Toward register spilling security using llvm and arm pointer authentication. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 41, 3757–3766

  60. [2024]

    IETF Datatracker

    Arm’s Platform Security Architecture (PSA) Attestation To- ken. IETF Datatracker. URL: https://datatracker.ietf.org/doc/ draft-tschofenig-rats-psa-token/ . accessed: March 17, 2025

    2025