Hypernetwork-Based Dynamic Adaptation

• Hypernetwork-based dynamic adaptation is a method where an auxiliary network generates target model parameters on-the-fly.
• This approach enables rapid model adjustments to new data, reducing retraining time and computational overhead.
• Applications in meta-learning, reinforcement learning, and computer vision demonstrate its potential for enhanced performance.

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.

1. 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.
2. 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
3. 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.
4. 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:
  • 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.

1. 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.
2. 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.

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