---
title: Hypernetwork-Based Dynamic Adaptation
url: https://www.emergentmind.com/topics/hypernetwork-based-dynamic-adaptation
type: topic
---

# Hypernetwork-Based Dynamic Adaptation

Below is a consolidated, expert-level technical overview of the ARMv8.1-M Pointer Authentication and Branch-Target Identification extension (PACBTI), drawn from the full content of Cirne et al.’s RunPBA paper and related ARM documentation. Where the paper does not explicitly give low-level hardware diagrams or formal MAC formulas, we note this and provide the standard view of PACBTI as specified by ARM.

1. Motivation and Threat Model  
– Motivation  
  • Control-flow hijacking via code reuse (Return-Oriented Programming, ROP; Jump-Oriented Programming, JOP) remains one of the most potent attacks on memory-safe embedded devices, even under DEP/NX.  
  • Pure software CFI incurs non-trivial runtime overhead and code size growth; custom hardware CFI requires non-standard silicon and raises cost.  
  • ARMv8.1-M introduced a standardized, off-the-shelf ISA extension—PACBTI—that can enforce fine-grained backward-edge and forward-edge integrity with minimal performance penalty.  
– Threat Model  
  • Adversary controls Non-Secure Processing Environment (NSPE) memory: arbitrary reads and writes within MPU/DEP constraints, but cannot tamper with Secure Processing Environment (SPE) or TF-M code and data.  
  • No additional NSPE CFI is present; DEP/NX may be enabled.  
  • Attacker may exploit buffer overflows or format-string bugs to hijack control flow, and may attempt brute-force, reuse, or side-channel attacks on PAC, as well as Function-Oriented Programming (FOP) attacks on BTI.  
  • Physical attacks, side-channel beyond brute-force, and attacks on SPE are out of scope.  

2. Architecture and Hardware Design  
PACBTI comprises two cooperating hardware subsystems wired into the Cortex-M pipeline and execution core:  
  A) Pointer Authentication (PA) Unit  
    – A QARMA-based MAC core that computes a short signature (“PAC”) over a 32-bit pointer plus a 32-bit modifier, under a secret key (Key_A or Key_B) stored in dedicated PA key registers.  
    – Integrated into the execution pipeline so that a single PAC‐generation or PAC‐authentication instruction invokes the MAC core, returns the tagged pointer in the destination register, and raises a synchronous UsageFault on authentication failure.  
    – Control registers (e.g., PACR_EL1 in A-series, analogous in M) let firmware enable/disable PA and select which key to use for forward/backward edges.  
  B) Branch-Target Identification (BTI) Unit  
    – A small hardware checker on each indirect branch instruction: before executing a BX or BLX via register, the processor checks the target instruction’s B‐pool bit (the “landing-pad” annotation) in the instruction’s fetch buffer.  
    – If the target is not marked as a valid landing pad, the core raises a synchronous UsageFault. Landing-pad annotations are placed by the compiler at the entry of each function (or other legitimate indirect‐call targets).  
  • Side-effects on memory subsystem: PACs are stored in the top unused bits of the 32-bit pointer in Cortex-A, but on Cortex-M85/M52 PAC is held in a separate hardware register and merged/demerged on store/load, so no change to memory format.  
  • Pipeline integration: Both PA and BTI checks occur pre-execution, generating faults before side-effects; no extra loads/stores are required.  

3. Instruction-Set Extensions  
ARMv8.1-M adds the following new instructions (paired for forward- and backward-edges):  
  – PACIA (Pointer Authenticate using Key A, forward-edge call tagging)  
  – PACIB (Pointer Authenticate using Key B, backward-edge return tagging)  
  – AUTIA (Authenticate pointer tagged with Key A, and strip PAC; UsageFault on mismatch)  
  – AUTIB (Authenticate pointer tagged with Key B, and strip PAC; UsageFault on mismatch)  
  – BTI   (Branch Target Identification hint; marks the next instruction as a valid landing pad)  
Semantics sketch, for a register X:  
  PACIB X                            ; X := tag ‑-> MAC_KB(X, modifier)  
  ... BLX X …  
  AUTIB X                           ; verify MAC_KB, raise UsageFault if wrong  
  BTI                              ; annotate this location as valid indirect‐branch target  
  BX LR                            ; return to link register, which must have valid PAC  

4. Formal Description  
Cirne et al. do not provide full formulas. The standard ARM model is:  
  Let f_K(P, M) = QARMA_MAC under key K over pointer P and modifier M.  
  On PAC generation:  
    PAC = f_K(P, M)  
    store tagged pointer P′ = P ∥ PAC bits  
  On authentication:  
    if f_K(P, M) ≠ extracted_PAC(P′) then UsageFault  
In a more abstract form:  
  ∀ calls i, let P_call_i be return address, M_sp_i be stack-pointer modifier, K_B the return key.  
  On return: AUTIB validates f_{K_B}(P_call_i, M_sp_i) = stored_PAC_i.  

5. Integration with RunPBA (Runtime Attestation Protocol)  
– Prover setup (on device):  
  1. At boot, NSPE code calls TF-M SPE service to generate a fresh random key for PA via secure RNG.  
  2. NSPE initializes PACBTI control registers: enable PACIB/PACIA and BTI.  
  3. Compile-time: all function calls/instructions are augmented with PAC/BTI.  
  4. TF-M Application Root-of-Trust (RunPBA) is installed in SPE to handle faults and attestation.  
– During normal operation:  
  • Any PAC or BTI violation in NSPE triggers a UsageFault → escalated to Secure HardFault.  
  • Secure HardFault handler in SPE invokes a fast-level interrupt (FLIH) in the RunPBA partition to snapshot CC context, then a second-level interrupt (SLIH) to store fault context in ITS. NSPE is held in an infinite-loop.  
– On attestation request:  
  1. Verifier sends nonce.  
  2. PSA Initial Attestation Service (in SPE) invokes RunPBA API to retrieve:  
     a) “runtime fault” bit (has a PACBTI fault occurred?)  
     b) current PACBTI enable/disable status bits  
  3. Attestation token is assembled in CBOR Web Token format, including:  
     • security-lifecycle claim (first 8 bits: RunPBA/SPE state; next 8 bits: bits for PACIA, PACIB, BTI, and “runtime-fault”).  
     • prover’s nonce, device identity, other static claims.  
  4. Token is signed with device-unique key and returned to verifier.  
– Verifier checks signature, nonce freshness, and inspects the RunPBA lifecycle bit. A set “runtime-fault” = NSPE in compromised state.  

6. Security Analysis  
Cirne et al. classify PACBTI attacks into four categories for PA and one for BTI:  
  A) Brute-force: trying all PAC values to pass authentication. Mitigations: 32-bit PAC on M makes brute-force ≈2^32; each failure crashes device (key rollover); ephemeral key per reboot.  
  B) Malicious PAC generation: once code execution is hijacked, instructions that generate PAC exist in binary. Requires full control and correct modifiers.  
  C) Reuse attacks: reusing a recorded PAC from one call in another. Defeated by using SP as modifier (but SP often repeats), key rollover, fresh keys.  
  D) Side-channel-speculative: on M, PAC failure traps synchronously → no silent mis‐speculation leak; no branch speculation beyond single‐cycle predicted fetch.  
  E) Function-Oriented Programming (FOP) vs. BTI: BTI landing pads exist at every function prologue → any function is a valid target, FOP dispatchers remain possible. Hard to exploit in practice on Cortex‐M (gadgets rare, manual chain construction required).  
RunPBA further raises cost: any PAC/BTI violation causes immediate stoppage and reset or attested failure.  

7. Performance Evaluation  
– Functional tests run on ARM FVP Corstone-310 (Cortex-M85); performance measured on Renesas EK-RA8M1 (Cortex-M85) with Nordic PPK2 power profiler.  
– Benchmarks:  
  • BEEBS (30 tests, looped 1024×; 3 crashes excluded; 3 anomalous tests with compiler inlining removed)  
  • CoreMark-Pro (single-core subset; 2 anomalous tests excluded)  
– Results (PACIA+PACIB+BTI enabled vs. disabled, -O0 build):  
  Metric     | BEEBS   | CoreMark-Pro  
  Execution time overhead (geomean) | 4.7%  | 1.0%  
  Energy (current × time) overhead   | 4.8%  | 1.0%  
  Firmware size overhead       | 6.8%  | 4.7%  
  Worst-case single test (recursion) | +28%  | (radix2-64k) +2.6%  
– Breakdown: PA instructions add 2 instructions per call/return; BTI is zero-cycle hardware check. The bulk of overhead comes from many small function calls (e.g. recursive Fibonacci). In heavy-compute tests calls are fewer, so <2% overhead.  

8. Discussion and Future Work  
Limitations and trade-offs:  
  • BTI cannot distinguish between intended and unintended landing pads → vulnerable to FOP. Mitigation: hardened compilers to avoid dispatcher gadgets.  
  • TOCTOU window: attacker could disable PACBTI in privileged NSPE code and re-enable before attestation. SPE cannot watch PACR registers via DWT, so cannot instantly detect a disable event.  
  • Requires minimal TF-M core changes (HardFault routing) and added RunPBA partition—adds to maintenance burden on TF-M forks.  
  • No dedicated hardware counters or monitors to audit per-function PAC usage; all tracing is reactive on fault.  
Future directions:  
  • Compiler passes to perform CFG analysis and selectively insert PAC/BTI only where needed, reducing code‐size and cycle overhead.  
  • Combination with resource-efficient ASLR and fine-grained memory protections.  
  • Investigation of PACBTI’s resilience to novel data-flow or mixed control-data attacks.  
  • Hardware support for real-time monitoring of PAC enable bits (e.g. via a trace or debug port).  

In summary, ARM’s PACBTI extension provides a lightweight, hardware-accelerated CFI mechanism suitable for low-end Cortex-M devices. When leveraged by RunPBA and TF-M, it enables true runtime attestation of control-flow integrity with single‐digit percent overhead—dramatically improving security over purely software CFI or custom IP cores, and offering a practical path to deploy CFI at scale in modern IoT and embedded platforms.

Source: https://www.emergentmind.com/topics/hypernetwork-based-dynamic-adaptation