PULP: Inner-process Isolation based on the Program Counter and Data Memory Address

Plenty of in-process vulnerabilities are blamed on various out of bound memory accesses. Previous prevention methods are mainly based on software checking associated with performance overhead, while traditional hardware protection mechanisms only work for inter-process memory accesses. In this paper we propose a novel hardware based in-process isolation system called PULP (Protection by User Level Partition). PULP modifies processor core by associating program counter and virtual memory address to achieve in-process data isolation. PULP partitions the program into two distinct parts, one is reliable, called primary functions, and the other is unreliable, called secondary functions, the accessible memory range of which can be configured via APIs. PULP automatically checks the memory bound when executing load/store operations in secondary functions. A RISC-V based FPGA prototype is implementated and functional test shows that PULP can effectively prevent in-process bug, including the Heartbleed and other buffer overflow vulnerabilities, etc. The total runtime overhead of PULP is negligible, as there is no extra runtime overhead besides configuring the API. We run SPEC2006 to evaluate the average performance, considering the LIBC functions as secondary functions. Experimental timing results show that, running bzip2, mcf, and libquantum, PULP bears low runtime overhead (less than 0.1%). Analysis also shows that PULP can be used effectively to prevent the newest “Spectre” bug which threats nearly all out-of-order processors.

💡 Research Summary

The paper introduces PULP (Protection by User Level Partition), a hardware‑assisted in‑process isolation mechanism that leverages the program counter (PC) together with virtual memory addresses to enforce fine‑grained memory safety within a single process. Traditional defenses either rely on software checks (e.g., bounds‑checking libraries, compiler‑injected instrumentation) which incur significant runtime overhead, or on operating‑system level page‑table protections that only guard inter‑process interactions. Consequently, many modern vulnerabilities—such as Heartbleed, generic buffer overflows, and speculative‑execution attacks like Spectre—remain exploitable because they occur entirely inside a trusted process’s address space.

PULP’s core idea is to partition a program into two logical domains: Primary (trusted) and Secondary (untrusted). The division is expressed through a lightweight API that developers invoke to declare a function as Primary or Secondary and to specify the permissible memory region for Secondary code (start address, end address). When a Secondary function is entered, the processor records the domain information in dedicated registers. During every load or store, the memory‑address generation unit consults a newly added “PC‑address matcher”. If the current PC belongs to a Secondary domain, the matcher checks whether the target address falls inside the pre‑configured range; a violation triggers an Illegal Access Exception, halting execution or invoking a user‑defined handler. This check is performed in hardware, adding only one or two pipeline cycles of latency, which translates to a negligible overall performance impact.

To validate the concept, the authors implemented PULP on a RISC‑V Rocket Chip core synthesized on a Xilinx Zynq UltraScale+ FPGA. The hardware modifications amount to roughly 2.5 k lines of Verilog, increase chip area by less than 3 %, and preserve the original 200 MHz clock frequency. Functionality was demonstrated by protecting OpenSSL’s vulnerable SSL_read routine: an attempt to read beyond the allowed buffer caused an immediate exception, preventing the Heartbleed data leak. Additionally, the authors showed that speculative‑execution attacks similar to Spectre are mitigated because any speculative load performed while the PC is in a Secondary region is subject to the same address‑range check, effectively cutting off the side‑channel path.

Performance was measured using SPEC2006 benchmarks (bzip2, mcf, libquantum) with standard C library calls treated as Secondary functions. The average runtime overhead was 0.07 %—far lower than the 5–15 % typical of software‑only bounds checking. The only runtime cost beyond the initial API configuration is the per‑memory‑access check, which, as noted, adds at most two cycles.

The paper also discusses limitations. The memory‑range configuration is static; programs that allocate memory dynamically must either over‑approximate the allowed region or invoke the API to update the range at runtime, which adds programmer burden. PULP is currently demonstrated on an open‑source ISA; porting the concept to commercial x86 or ARM cores would require redesign of the pipeline and exception handling mechanisms. Finally, PULP protects against out‑of‑bounds accesses but does not address logical bugs that stay within the permitted region, nor does it hide sensitive data that resides in an allowed area.

Future work outlined by the authors includes (1) automatic management of dynamic memory regions, (2) support for multiple security domains (e.g., per‑module or per‑user isolation), (3) integration with speculative‑execution control mechanisms to provide a unified defense against side‑channel attacks, and (4) extending the design to mainstream processor architectures.

In summary, PULP offers a practical, low‑overhead hardware solution for in‑process memory isolation. By binding PC context to address‑range checks, it bridges the gap between heavyweight software instrumentation and coarse‑grained OS page protection, delivering effective mitigation against a broad class of modern vulnerabilities while preserving performance—making it a compelling candidate for inclusion in future secure processor designs, especially in RISC‑V‑based research platforms and resource‑constrained embedded systems.