Space-Control: Process-Level Isolation for Sharing CXL-based Disaggregated Memory
CXL 3.0 lets multiple hosts share remote memory, but once a host is in, every process on it has unrestricted access. Space-Control fixes this with a hardware-software co-design that brings process-level isolation to shared disaggregated memory, without trusting the OS.
Read the paper Explore the code
Originally published on March 6, 2026
The Gap in CXL Sharing
Memory disaggregation via CXL is transforming how data centers allocate and share memory. CXL 3.0 takes a major step forward: multiple compute hosts can now map the same physical memory region on a remote device, enabling workloads like shared graph analytics, distributed key-value stores, and ML inference to pool memory at cache-line granularity.
But there is a critical security gap.
CXL’s access control is host-level: once the Fabric Manager grants a host access to a shared region, every process on that host, including a compromised kernel on a remote host, can read or write the entire range. This violates the principle of least privilege. Stark et al. describe it plainly as “sledgehammer-level protections.”
Existing solutions don’t fit the CXL model: TEEs (SGX, TDX, AMD SEV) cannot share memory between enclaves across hosts. CHERI capability pointers demand ISA and compiler changes everywhere. OS-managed schemes like MPK and MTE assume the kernel is trustworthy, exactly what we cannot assume.
The question: How do you isolate individual processes in shared disaggregated memory, even if the OS is compromised, with minimal overhead?
Introducing Space-Control
Space-Control answers that question with a hardware-software co-design built around three components.
SPACE :: The Hardware Root of Trust
The Secure Process Attribute Context Engine (SPACE) lives on each host. It assigns hardware process IDs (HWPIDs) independently of the OS and, at every context switch, generates a cryptographic label that binds the running process to its permitted memory ranges. This label is cross-checked against one issued by the Fabric Manager. Only when the two match does SPACE tag the process’s outgoing memory addresses as authenticated, using spare bits in the physical address. The kernel cannot forge these tags.
Permission Table :: Stored in the Shared Memory Itself
Rather than replicating per-host metadata, Space-Control keeps a single sorted permission table inside the shared disaggregated memory, managed by the Fabric Manager. Each entry defines an arbitrary-length range and the set of processes permitted to access it. Permissions can be created, updated, and revoked dynamically; updates propagate instantly via CXL’s back-invalidate snoop mechanism.
This design is remarkably space-efficient: even in the worst case (one entry per 4 KiB page), the metadata overhead is only 1.56% of total shared memory, 128× less than a naïve flat table approach.
Permission Checker :: On-Chip Enforcement at the Egress
The permission checker sits between the last-level cache and the CXL port. Every load/store to the shared memory is validated against the permission table before it commits. A small permission cache (as little as 2 KiB) amortizes repeated lookups, achieving a 99.9% hit rate for a 16 GiB shared region.
Local memory pages belonging to trusted processes are also encrypted on-chip, ensuring confidentiality even if the kernel remaps page tables.
Figure 1 shows the system-level architecture of Space-Control. While green in general represents trusted components, the darker shade represents additional hardware. The FM manages the permission table stored in SDM. The key difference between Space-Control and CXL is while CXL allows all processes and the kernel on host3 to access the shared memory, we only allow P1 to access that data.
Figure 1. Space-Control architecture providing process-level isolation for shared disaggregated memory.
With the addition of new trusted hardware, only the authorized process P1 on host3 is allowed access to the shared memory.
In CXL, any process on host3 can access that data.
How It Compares
| CXL 3.0 | DeACT | CHERI | Space-Control | |
|---|---|---|---|---|
| Process-level isolation | ✗ | ✗ | ✓ | ✓ |
| OS-independent enforcement | ✗ | ✗ | ✗ | ✓ |
| Scalable metadata | ✓ | ✓ | ✗ | ✓ |
| Works with existing CXL hardware | ✓ | ✗ | ✗ | ✓ |
Space-Control is the only approach that satisfies all four properties at once. In addition, permissions are transparent to the OS and the CXL hardware.
Performance
Space-Control is evaluated on a gem5 + SST simulation of up to 8 hosts sharing a DDR4 memory device, running GAPBS graph kernels on a shared graph.
- With coarse permissions (a single entry covering the full shared region), overhead over a baseline CXL system is just 3.3% with a 16 KiB permission cache.
- Overhead scales sub-linearly as the number of hosts grows, from 7.3% at one host to 12.1% at eight.
- Even in the worst-case fragmentation scenario, a 2 KiB permission cache recovers most of the performance loss, delivering a 2.3× improvement over the uncached configuration.
- Hardware cost is minimal: 4 KiB of SRAM for the checker, ~1 KiB for SPACE state, and two shadow registers per core.
The full breakdown of performance contributors, sensitivity analyses, and comparisons to DeACT, flat tables, and Mondrian are all in the paper.
Citation
@misc{goswami2026spacecontrolprocesslevelisolationsharing,
title={Space-Control: Process-Level Isolation for Sharing CXL-based Disaggregated Memory},
author={Kaustav Goswami and Sean Peisert and Venkatesh Akella and Jason Lowe-Power},
year={2026},
eprint={2603.06951},
archivePrefix={arXiv},
primaryClass={cs.AR},
url={https://arxiv.org/abs/2603.06951},
}
Learn More
The paper covers the full threat model, microarchitecture, security analysis, and evaluation methodology in detail.
To reproduce the experiments or explore the implementation, the source code is available on GitHub as a branch of the gem5 simulator.
The README-SPACE-CONTROL.md in the repository walks through every experiment step by step.
Questions? Email kggoswami@ucdavis.edu.
