A Hardware Primitive for 'Who Gets to Change the Locks' — Bounded Delegation Comes to RISC-V MCUs

New RISC-V hardware enforces not just who can access what, but who can change access rules and how far those changes can reach — at zero latency cost.

Imagine you're the building superintendent of a large apartment complex. You can hand a master key to a floor manager, but today's key-copying machines have no way to say 'this copy only opens doors on floor 3.' The floor manager could, in theory, cut a copy that opens every door in the building. That's the state of memory protection on most microcontrollers today: you can say who configures protection rules, but you can't constrain what rules they're allowed to write. This paper adds the missing constraint — a hardware-enforced envelope that says 'your key-copies can only cover these doors.' The committed claim: bounded configuration authority is a missing primitive in MCU protection hardware, and this paper builds it. Existing RISC-V and ARM protection mechanisms (PMP, ePMP, IOPMP, TrustZone, SMPU) let you restrict which software domain can modify protection registers, but none constrain what policy that domain may then create. A domain authorized to reconfigure protection rules can expand its own reach or stomp on boundaries set by others. The paper introduces an ownership-aware model where every protection rule has an explicit owner, rule modifications must stay within the owner's existing authority envelope, and delegation of configuration rights is recursive but always bounded by the delegator's scope. The architecture is a 'World Checker' — a hardware module that sits in the RISC-V SoC alongside the CPU, intercepting configuration writes to protection-rule registers. Before any rule change commits, the checker validates that the new rule's address range is contained within the owning domain's range and that the requested permissions don't exceed what the owner holds. This validation happens off the normal memory-access datapath, meaning the standard access-check pipeline — the hot path — sees zero additional latency. The design is integrated into an open-source CVA6-based SoC on FPGA. The ladder position is strong for this specific niche. The paper benchmarks against two alternatives for dynamic policy reconfiguration: hypervisor-mediated transitions and trusted-firmware-mediated transitions. Direct reconfiguration under delegated authority cuts policy-transition latency by 89.5% versus hypervisor mediation and 94.6% versus firmware mediation. The comparison is apples-to-apples for the use case (OTA firmware update requiring runtime policy change), though it's important to note these aren't competing protection models — they're competing reconfiguration strategies. The hardware overhead is modest: 7.1% LUT increase and 1.2% flip-flop overhead for eight rules, with no degradation to access latency or operating frequency. The integrity picture is decent but bounded. Validation is FPGA-based — a real hardware implementation, not just simulation, but also not silicon. The OTA update case study is a single scenario, not a comprehensive security evaluation with adversarial testing. The paper doesn't present formal verification of the ownership invariants, which would be the gold standard for a security primitive. All artifacts are promised as open-source, which enables independent scrutiny, but no independent replication exists yet. The milestone question maps to RISC-V ecosystem adoption. Eight rules on a CVA6 core is a proof of concept. The real unlock would be integration into RISC-V specification drafts (IOPMP or a successor) and adoption by commercial silicon vendors. The paper explicitly positions itself as supporting 'the evolution of RISC-V specifications,' which suggests the authors see spec influence as the next concrete step. The scaling question — how overhead grows with 32 or 64 rules, or with more complex ownership hierarchies — remains unanswered. The obvious experiment not run is adversarial security evaluation: red-teaming the ownership model to find bypass conditions, especially around edge cases in recursive delegation chains or concurrent reconfiguration from multiple domains. The honest read is (a) — this is a systems-architecture paper from a hardware group, not a formal-methods or security-analysis group, and adversarial evaluation is a different skill set and publication venue. Expect a follow-up from either this team or a collaborating security group.