---
title: 'RunPBA: Runtime Attestation for MCUs'
url: https://www.emergentmind.com/topics/runpba
type: topic
---

# RunPBA: Runtime Attestation for MCUs

RunPBA is a hardware-based runtime attestation framework designed for microcontrollers, leveraging the Pointer Authentication and Branch Target Identification (PACBTI) extension introduced in ARMv8.1-M. Its primary goal is to provide robust, low-overhead defenses against control-flow attacks in resource-constrained embedded environments without requiring custom hardware modifications, while integrating seamlessly with industry-standard attestation mechanisms such as ARM PSA and Trusted Firmware-M [2512.12729].

## 1. Motivation and Threat Model

The proliferation of embedded microcontrollers (MCUs) in critical infrastructure has intensified the need for protecting these systems from control-flow hijacking attacks, including Return-Oriented Programming (ROP), Jump-Oriented Programming (JOP), and Function-Oriented Programming (FOP). Constraints typical to MCUs—low energy consumption, strict timing requirements, and limited computational resources—render conventional software-based Control-Flow Integrity (CFI) and attestation schemes unsuitable due to prohibitive overhead or dependence on non-standard silicon.

RunPBA specifically aims to:
- Detect all runtime deviations from legitimate control flow, closing “time-of-check, time-of-use” (TOCTOU) races inherent to traditional attestation models.
- Operate exclusively with off-the-shelf ARM Cortex-M silicon supporting PACBTI, with no hardware additions.
- Limit runtime, energy, and code-size overhead to a few percent.
- Interoperate with attestation standards including PSA and Trusted Firmware-M.

The threat model assumes adversaries may read or write arbitrary memory in the Non-Secure Processing Environment (NSPE) outside Memory Protection Unit (MPU) and Data Execution Prevention (DEP) controls, including mounting ROP/JOP/FOP and PAC tag brute-force attacks. Physical, side-channel, and Secure Processing Environment (SPE) attacks, and compromise of long-term attestation keys, are out of scope [2512.12729].

## 2. PACBTI Extension on ARM Cortex-M

The PACBTI extension, available on ARM Cortex-M85/M52 via ARMv8.1-M, integrates Pointer Authentication (PA) and Branch Target Identification (BTI) into the instruction set:

- **Pointer Authentication (PA):** Every code pointer is “signed” with a 32-bit Pointer Authentication Code (PAC) generated by a keyed MAC (e.g., QARMA). The PAC is stored in a reserved register. When the pointer is used, the MAC is recomputed with context-dependent modifiers (typically the stack pointer) and checked before use. A mismatch triggers a UsageFault exception.
- **Branch Target Identification (BTI):** Each valid indirect branch target must be marked with a BTI “landing pad” instruction. Indirect branches to arbitrary instructions without the BTI opcode are prevented at the hardware level, enforcing that control-flow transfers only to marked function entries.
- **Pipeline Integration:** With PACBTI-enabled toolchains (LLVM-17, ArmCC), function calls and returns are instrumented to add pointer authentication and branch safety checks automatically. The PA hardware stage executes MAC operations (5–10 cycles per PAC/AUT instruction); BTI checks occur as a single pipeline cycle without explicit instruction overhead [2512.12729].

## 3. End-to-End Runtime Attestation Workflow

RunPBA extends the ARM PSA Initial Attestation service (Trusted Firmware-M’s Secure Partition) to include real-time control-flow integrity status:

1. **Attestation Protocol:**
   - The verifier sends a nonce-challenge to the device.
   - The attestation service in the Secure Processing Environment queries the RunPBA Application Root-of-Trust for current PACBTI status and fault history, and reads NSPE control registers.
   - Claims are packed into a CBOR-Web-Token, including security lifecycle bits (e.g., NSPE compromised on PACBTI fault, RunPBA own error status), PAC/BTI enablement flags, the received nonce, and static firmware measurements.
   - The token is signed with a device-unique key and returned to the verifier, which checks the signature, nonce, and security status bits.

2. **Fault Management:** 
   - Hardware faults (UsageFault) resulting from PAC/BTI violations in NSPE are escalated via modified SPE HardFault handlers and logged by RunPBA’s partition for attestation reporting.

3. **Token Generation Example:**
   ```c
   function GenerateAttestation(nonce N):
       state = RunPBA.get_state()
       ctlr = Read(NSPE.PACBTI_CTRL)
       claims = {
         "lifecycle": (plat_lc <<8) | (runpba_state),
         "pac_enabled": ctlr.PA,
         "bti_enabled": ctlr.BTI,
         "nonce": N,
         ...
       }
       token = CBOR_Web_Token(claims)
       sig   = Sign(device_priv_key, token)
       return (token, sig)
   ```
   [2512.12729]

## 4. Implementation Architecture

The RunPBA proof-of-concept is implemented as an Application Root-of-Trust (RoT) partition in Trusted Firmware-M v1.5, evaluated using Arm Corstone-310 FVP and Renesas EK-RA8M1 (Cortex-M85):

- **TF-M Integration:** Minor modifications are required to the TF-M core, redirecting UsageFaults from NSPE as SPE HardFaults and extending attestation code to incorporate PACBTI status via the RunPBA partition.
- **RunPBA Partition:** Responds to PACBTI faults with a fast-latency first-level interrupt handler (FLIH) to snapshot context, and a deferred second-level handler (SLIH) to securely persist fault evidence.
- **Initialization:** At boot, PACBTI keys are generated from the TF-M random number generator, PAC/BTI are enabled, and PAC tags are calculated as per ISA requirements.
- **Toolchain:** Builds employ LLVM 17.0.1 with appropriate CPU/mattr flags and ARM GNU Toolchain 13.2.

The incremental memory footprint due to PACBTI code transformations is approximately 6–7% (including RunPBA’s 16 kB TF-M API stubs) [2512.12729].

## 5. Performance Evaluation

The efficiency and practicality of RunPBA are demonstrated through detailed benchmarking:

- **Benchmarks:** BEEBS (30 integer/memory/control microbenchmarks) and CoreMark-Pro (industry standard for embedded CPUs) on Renesas EK-RA8M1 with Nordic Power Profiler Kit II.
- **Measurement Methodology:** Both suites compiled with optimizations disabled (–O0) to maximize branch diversity; all benchmarks run with PACBTI both enabled and disabled.
- **Calculation of Overhead:** Time and energy overheads computed as geometric means of the ratio of PACBTI-enabled to baseline execution for each test, excluding any artificial decreases.
- **Results:**
  - BEEBS: 4.7% time and 4.8% energy overhead (max test: 28% for heavy recursion), code size increase +6.8%.
  - CoreMark-Pro: 1.1% time and 1.0% energy overhead (max: 2.6% for large FFT), code size increase +4.8%.

A key comparative table highlights RunPBA’s hardware simplicity and code efficiency versus prior hardware-assisted CFI approaches (Silhouette, SuM):

| Solution            | BEEBS Overhead | CoreMark-Pro Overhead | Code Size Overhead | Extra Memory                |
|---------------------|:--------------:|:---------------------:|:------------------:|:---------------------------:|
| Silhouette [Zhou20] |     3.4%       |         1.3%          |      16.2%         | parallel shadow stack        |
| SuM [Choi24]        |     2.8%       |         2.6%          |        8.8%        | compact shadow stack + DWT   |
| RunPBA (PACBTI)     |     4.7%       |         1.1%          |        6.8%        | none (uses r12 register)     |

RunPBA eliminates the need for shadow stacks or extra regions, leveraging in-silicon hardware MACs for pointer authentication [2512.12729].

## 6. Limitations and Future Work

Notable limitations include:
- Exposure to FOP-style attacks, as BTI permits indirect branches to any function prologue unless prevented by compiler hardening.
- Potential TOCTOU exploitation if privileged NSPE code disables PACBTI and reenables it before the next attestation, since RunPBA only checks status at attestation time.
- Absence of hardware watchpoints for PACBTI control registers, preventing real-time enforcement of register integrity.
- Necessity for TF-M modifications, particularly for correct fault escalation handling.

Areas for future research involve:
- Selective PAC/BTI instrumentation via per-CFG analysis to further minimize code overhead.
- Automated FOP detection/mitigation.
- Extension to PAC-based data-flow attestation.
- Formal verification of RunPBA SPE handler and attestation APIs [2512.12729].

## 7. Summary and Impact

RunPBA establishes that robust runtime attestation and CFI enforcement on MCUs is achievable with marginal overhead when leveraging mainstream ARM PACBTI extensions and industry-compliant attestation frameworks. This approach obviates the need for bespoke silicon or invasive memory modifications, significantly advancing practical security guarantees for next-generation embedded systems [2512.12729].

Source: https://www.emergentmind.com/topics/runpba