CPU Register Renaming Already Hides Your Secrets — This Paper Shows How to Exploit It

Privacy-enhanced computing without a dedicated enclave: reuse the register renamer for encryption, run 1.26x faster than sequestered units, at under a third the area cost.

Imagine you're playing a shell game, but instead of three cups and a pea, you have a hundred cups that are constantly being shuffled by a dealer who never stops moving. The dealer is the CPU's register renamer — a mechanism that already exists in every out-of-order processor to map architectural registers to a much larger pool of physical registers. This paper's core insight is that if you encrypt values before they enter the physical register file and decrypt them on the way out, the renamer itself becomes your privacy vault. Plaintext never touches any structure an attacker can probe, because the only place values exist in the clear is inside execution units during the cycle they're being computed. The committed claim: you can achieve Privacy-Enhanced Computing (PEC) — hiding program secrets from physical side-channel and memory-probing attacks — by piggy-backing on the existing register rename infrastructure, eliminating the need for a dedicated "sequestered encryption" (SE) unit that duplicates ALU resources. Previous PEC designs built a walled-off enclave inside the CPU with its own execution units, which meant encrypted code couldn't use the full width of the processor: no out-of-order execution, no vector units, no parallel pipelines. HPS-PEC tears down that wall. The ladder is concrete and honest. Across 25 VIP-Bench benchmarks with a 7-cycle QARMA-64 block cipher, HPS-PEC runs encrypted code at 3.41x the execution time of unprotected native code (geometric mean). Of that overhead, 1.03x is the inherent cost of writing data-oblivious code — a tax you pay regardless of the encryption mechanism. Compared to the SE baseline, HPS-PEC is 1.26x faster while consuming under one-third of the SE unit's dedicated silicon area. That area savings matters: chip real estate spent on a dedicated enclave is real estate stolen from caches, prefetchers, or additional cores. Architecturally, this belongs to the hardware-assisted confidential computing family — the same neighborhood as Intel SGX, AMD SEV, and ARM CCA, but at a finer grain. Rather than encrypting entire memory pages or VM contexts, HPS-PEC operates at register granularity, encrypting and decrypting individual register values as they move between the physical register file and execution units. The cipher used is QARMA-64, a lightweight tweakable block cipher designed for latency-sensitive hardware paths. The key structural bet is that the rename stage — already the narrowest pipeline stage in modern superscalar designs — can absorb the encrypt/decrypt logic without becoming the new bottleneck. Integrity is reasonable for a microarchitecture paper. The evaluation uses cycle-accurate simulation (gem5-based) against the VIP-Bench suite, which is the community benchmark for PEC workloads. The SE baseline is the strongest prior design in the literature, not a strawman. The 3.41x overhead number is a geometric mean across 25 benchmarks, which is the right aggregation for performance ratios. The authors are upfront that the 1.03x data-oblivious overhead is a floor you cannot remove. What's missing: no RTL synthesis or tape-out, so the area and timing claims for QARMA-64 integration rest on estimates, not silicon measurements. No independent replication. The milestone to watch: the 3.41x overhead is usable for security-critical code paths but not for general-purpose computation. Getting this below 2x — where encrypted execution becomes cheap enough to leave on by default for sensitive workloads — would change the adoption calculus. That likely requires either a faster cipher (sub-4-cycle latency) or architectural tricks to hide cipher latency more aggressively behind existing pipeline bubbles. The authors don't speculate on timeline, but cipher design and pipeline integration are both active areas. The obvious experiment not run: testing HPS-PEC on a real RTL implementation or FPGA prototype to validate that QARMA-64 integration doesn't blow up the critical path of the rename stage. My read: this is a (a) compute/resource constraint — RTL implementation and FPGA prototyping are expensive and slow, and the conceptual contribution stands on its own for a conference paper. The next paper from this group will almost certainly be the hardware validation.