Program Counter Security Model Overview

• Program Counter Security Models are formal paradigms that tie execution privileges to runtime PC values, defining and enforcing security domains.
• They incorporate methodologies such as hardware range checks, cryptographic return address verification, and IFC type systems to mitigate control-flow and data leakage attacks.
• Implementations like PULP and PACStack demonstrate practical, low-overhead isolation and integrity enforcement, balancing performance with robust security guarantees.

A Program Counter Security Model is any formal or enforced security paradigm in which access rights, privilege domains, or security invariants are defined or checked as a function of the code’s program counter (PC) value at runtime. These models arise in diverse domains: practical hardware-software in-process isolation, cryptographic integrity for control flow, and semantic enforcement of information flow in programming languages. They systematically tie code trustworthiness or sensitivity to the code region’s address—rendering security a function of where in the code one is executing, not merely what is being executed.

1. Domains, Formalization, and Access-Control Predicates

Program Counter Security Models partition executing code into mutually exclusive domains, each identified by program counter intervals. In hardware isolation proposals such as PULP ("PULP: Inner-process Isolation based on the Program Counter and Data Memory Address" (Zhu et al., 2018)), the model partitions the address space as follows:

• Primary (trusted) domain: All instructions with PC within $[PPCR_s, PPCR_e]$. These may access the entire data space.
• Secondary (untrusted) domains: Each secondary function has PC intervals $[PC_{s,i}^{start}, PC_{s,i}^{end}]$, with $i \in \{1,\dots,N\}$. Memory accesses by code running with PC in $[PC_{s,i}^{start}, PC_{s,i}^{end}]$ are restricted to $[A_{s,i}^{low},A_{s,i}^{high}]$.

The central access-control predicate becomes:

$$\text{allow\_access}(PC, A) \iff \left[ PC \in D_p \right] \lor \left[ \exists i: PC \in D_{s,i} \land A_{s,i}^{low} \leq A \leq A_{s,i}^{high} \right]$$

This model strictly binds permissible data accesses to the code region currently executing.

In language-based information-flow frameworks ("Giving Semantics to Program-Counter Labels via Secure Effects" (Hirsch et al., 2020)), the program counter label $p$ (drawn from a security lattice) captures the current sensitivity context, enforcing that side effects (e.g., writes, exceptions, divergence) in code under $p$ are not observable by lower security levels. The typing judgment $\Gamma \vdash_p e : \tau$ means all effects in $e$ are at least as sensitive as $[PC_{s,i}^{start}, PC_{s,i}^{end}]$0.

2. Microarchitectural and Software Realizations

Hardware: PULP’s RISC-V Modifications

PULP’s model (on Rocket-Chip, RISC-V):

• Registers instantiated:
  • $[PC_{s,i}^{start}, PC_{s,i}^{end}]$1 for primary code PC bounds
  • For each $[PC_{s,i}^{start}, PC_{s,i}^{end}]$2: $[PC_{s,i}^{start}, PC_{s,i}^{end}]$3 for secondary domain memory bounds
  • $[PC_{s,i}^{start}, PC_{s,i}^{end}]$4 (Return Address Register) for enforcing control-flow integrity (CFI) at domain crossings
• Pipeline checks:
  • Instruction fetch: Code type classified as kernel/primary/secondary via PC check
  • Load/store: If in secondary domain, effective address is range-checked via comparators shadowing the ALU
  • Return: Return address is compared to RAR, trapping on mismatch

API:

Primary code configures secondary ranges via start_protect(addr, len, cfg, index) and end_protect(index), which set/clear SMAR registers, invoked with special CSR instructions. On context switch, kernel saves/restores PPCR/SMAR/RAR.

Cryptographic CFI: Authenticated Call Stack (ACS)

PACStack (Liljestrand et al., 2019) applies a program-counter-tied integrity check to function return operations:

• On each call, return address $[PC_{s,i}^{start}, PC_{s,i}^{end}]$5 is bound to a chained authenticated token $[PC_{s,i}^{start}, PC_{s,i}^{end}]$6 (with $[PC_{s,i}^{start}, PC_{s,i}^{end}]$7 a tweakable MAC keyed by a hardware register). Only the latest $[PC_{s,i}^{start}, PC_{s,i}^{end}]$8 is kept in a protected register.
• On return, $[PC_{s,i}^{start}, PC_{s,i}^{end}]$9 are popped; the hardware verifies $i \in \{1,\dots,N\}$0.
• ARMv8.3-A implementations use pointer authentication codes (PAC), with dedicated instructions (pacia, autia).

This ensures any tampering of return addresses—program counters for return control-flow—is cryptographically detectable, binding executable stack integrity to the precise PC values in the call chain.

PC Label Tracking in IFC Type Systems

In monadic effect systems (Hirsch et al., 2020):

• Each typing judgment is indexed by a program-counter label $i \in \{1,\dots,N\}$1; side effects are only permitted if their sensitivity $i \in \{1,\dots,N\}$2 satisfies $i \in \{1,\dots,N\}$3.
• Typing and effect systems are unified semantically by an indexed monad/productor; noninterference follows by translation from PC-labeled typing to pure DCC via indexed effect monads.

3. Security Guarantees and Enforcement Properties

In-Process Isolation and Data Integrity

The hardware PC model (PULP) ensures:

• In-process bug prevention: Out-of-bounds accesses from untrusted code trap before memory or cache are touched. Violations are impossible once secondary domains are locked.
• Control-flow integrity: RAR guarantees returns from secondary to primary domains cannot be hijacked, protecting against ROP and similar attacks.
• Speculative execution side channels: Checks are in pipeline EX stage; thus, transient out-of-bounds accesses during speculation abort before line fill or are rolled back, preventing attacks like Spectre.

Cryptographically Bound Control Flow

PACStack’s ACS guarantees:

• Tamper detection: Any return-address modification is detected on function return; guessing a matching PAC has probability $i \in \{1,\dots,N\}$4 ($i \in \{1,\dots,N\}$5 in ARMv8.3-A).
• No secret state: All long-term secrets (PAC keys) reside in protected CPU registers and are never exposed to user memory.
• No compatibility loss: No changes to C code or binary are required; all protection is maintained via function prologue/epilogue instrumentation and hardware PAC.

IFC Models: Noninterference and Lower-Bound Principle

The PC label system provides:

• Noninterference: If $i \in \{1,\dots,N\}$6, then for all behaviors distinguishable only under label $i \in \{1,\dots,N\}$7, $i \in \{1,\dots,N\}$8 appears indistinct—no information leaks via reads, writes, exceptions, or even divergence (Hirsch et al., 2020).
• Lower-bound folklore: PC labels are proven to be lower bounds on all effects: if $i \in \{1,\dots,N\}$9 is typable under $[PC_{s,i}^{start}, PC_{s,i}^{end}]$0, then all effects $[PC_{s,i}^{start}, PC_{s,i}^{end}]$1 in $[PC_{s,i}^{start}, PC_{s,i}^{end}]$2 have $[PC_{s,i}^{start}, PC_{s,i}^{end}]$3. The equivalence is formalized as a Galois connection $[PC_{s,i}^{start}, PC_{s,i}^{end}]$4.

4. Representative Attacks Prevented

A summary of the key classes of attacks thwarted by these models:

Model/Domain	Protection Mechanism	Prevented Attacks
PULP (Zhu et al., 2018)	Hardware PC+address checks	Buffer overflows, Heartbleed, ROP, Spectre-class speculative-execution leaks
PACStack (Liljestrand et al., 2019)	Chained, PC-bound MAC on returns	Return-address tampering, Shadow-stack bypasses
IFC PC Labels (Hirsch et al., 2020)	PC label tracking in type system	Information leaks from side effects, exceptions, termination, implicit flow

PULP’s policy is both spatial (address bounds) and control-flow tight; PACStack’s is cryptographic, leveraging code address (return site) for binding. Language-centric PC labels prevent any effectful computation in a context of higher sensitivity from being observable at lower security levels.

5. Performance and Practical Considerations

• PULP hardware: <0.1% overhead in full SPEC2006 runs with library calls sandboxed; hardware area cost is 31% (extra registers and comparators), with ~28% more power, amortized in trusted settings (Zhu et al., 2018).
• PACStack: Instrumented C workloads show ≈2.75% (masked) or ≈0.86% (unmasked) slowdown versus baseline, with full micro-benchmark compatibility and no changes to source code (Liljestrand et al., 2019). SSL transaction load shows 4–13% overhead.
• IFC type systems: Proof burden is minimized and semantics are modular—adding new effects only requires associated monad definitions and effect labelings (Hirsch et al., 2020).

6. Semantic Unification and Theoretical Foundations

PC-based security models, while heterogeneous in realization, share the following semantic features:

• All effects being visible from a particular context are no more sensitive than the current PC label.
• Noninterference is unified via a translation to monadic semantics, where indexed (by security/effect) monads guarantee correct scoping and sensitivity of side effects.
• The folklore that "PC is a lower bound on effects" is made precise semantically via a Galois connection.

This theoretical framing provides a single underlying principle for practical hardware (PULP), cryptographic (PACStack), and language-based enforcement schemes.

7. Comparative Context and Limitations

Historically, program counter-based policies were enforced via ad-hoc mechanisms (hard-wired rules in type systems, or localized runtime checks). Semantic models such as those in (Hirsch et al., 2020) explain the unifying rationale and enable modular noninterference proof frameworks. In hardware, the principal limitation is area and power cost, as in PULP, or minimal performance overhead in PACStack, but both eliminate categories of in-process and control-flow attacks with minimal intervention.

A significant open problem remains the extension of PC-based enforcement to systems with algebraic effect handlers or unstructured I/O. The compositionality of PC-based semantic models depends on the existence of suitable monads for all effects in play; non-categorical or hyperproperty-based security definitions remain open for further research (Hirsch et al., 2020).

---

Program Counter Security Models therefore encompass and unify a class of security enforcement strategies—hardware, software, and semantic—that map privileges and trust directly to program counter state, yielding robust guarantees against a broad range of attacks with formally articulable semantics and practical, low-overhead implementations (Zhu et al., 2018, Hirsch et al., 2020, Liljestrand et al., 2019).