This is a report of the research done by Sophie Park as a RA during the summer of 2026.

CAPULET: Cache Pooling Metadata Caches in Secure Disaggregated Memory Systems

Or, more generally, secure memory through CXL

Compute Execute Link (CXL) is a protocol that allows CPUs to access memory through I/O ports. Traditionally, CXL has been used to connect CPUs to external DRAM. A CXL system’s memory capacity is not limited by the number of memory ports, as the connecting switches can be attached to more switches. Therefore CXL is extremely scaleable and well-addresses the RAM shortage caused by the AI boom. Furthermore, the only additional latency introduced by CXL is the physical link itself. Our research proposes that CXL also has the potential to connect CPUs to external SRAM. CAPULET (Cache Pooling Metadata Caches in Secure Disaggregated Memory Systems) is a protocol in which multiple CPUs can share their cache resources through CXL while also maintaining data integrity with a Binary Merkle Tree (BMT).

The primary goal of CAPULET is to reduce the miss rate of BMT lookups (i.e., to reduce the likelihood that the data we are looking for is no longer in cache) by letting multiple hosts pool their cache resources. CAPULET keeps track of the least-recently used block, which is where evicted data will go. Theoretically, this will mean that the cache will be filled with the most-likely-to-be-reused data. Some additional advantages of CAPULET are:

1. Cryptographical security through BMT hashing A Binary Merkle Tree (BMT) is a hash tree in which each leaf node contains the hash of a block of data (e.g., hash-based message authentication code (HMAC)), and every parent node holds the hash of the concatenation of all its children’s hashes. This means that the root node is a hash that encodes every child hash. And, in the case that the root node can be trusted, then we can use it to verify the integrity of all other nodes in the tree. (To ensure that the root node can be trusted, we store it on-chip.) This means that, if we keep record of which parent nodes we trust, we can significantly reduce the number of hash lookups necessary to verify any given block.
2. The inherent security of SRAM over DRAM Unlike DRAM, SRAM is not vulnerable to rowhammer attacks. This is because SRAM, unlike DRAM, does not leak charge and therefore does not require periodic refreshing. This is very important as the increasing demand for memory capacity means that the typical cell density of DRAM devices is also increasing, and cell density is directly related to how vulnerable a device is to rowhammer attacks.
3. Faster Fetch Times As CAPULET is a cache-centric protocol, naturally we will take advantage of the fact we do not need to fetch from DRAM as often. This means that the overall fetch times, and therefore the overall runtimes, will be faster.

The CAPULET emulator

For our research we used a python emulator and packet traces from running SPEC CPU 2017 benchmark workloads on gem5. There are three main classes in the emulator: Host (representing a single host CPU), Cache (which manages the local caches), MetadataCache (which manages the BMT system), and CAPULET (which is a wrapping class that orchestrates all of the other classes).

The emulator starts by reading the packet trace files in a specified directory (which we filled with traces of SPEC CPU 2017 benchmarks) and then feeding them into the CAPULET class, which then creates the specified number of hosts, each of which is given its own disjoint address range. Each host is then given a MetadataCache. The CAPULET class then progresses the traces/hosts based on their timestamps. The host with the smallest timestamp goes next. Once a host reaches the end of its current trace, CAPULET assigns it another trace. The emulator ends as soon as every host has completed at least one trace. (This is because trace lengths vary significantly, and the largest trace is dozens of times longer than the smallest trace)

The heart of CAPULET, the eviction-broadcast system, is in Cache.fill(). At every eviction, there is a p probability that the evicting host will broadcast a message to the other hosts. To find the ideal balance between messages sent vs. hit rate, we varied p throughout our simulations.

Results and limitations

Currently we are in the stage of running simulations with the SPEC CPU 2017 benchmark suite. The simulations vary in the number of hosts and eviction-message broadcast rates. Preemptively, we are getting overall hit rates of 97% to 99% for most hosts, and metadata hit rates generally increase as the rate of eviction-messages increase.

A potential limitation to note is that, in our simulations, all CPUs are running simultaneously, which may not necessarily be reflective of a real-world scenario. Furthermore, the timestamp density of the packet traces varied significantly, which may further exacerbate the prior point.

Next steps

I would be very interested in modifying the eviction-broadcast messages so that they are more intelligent than our current p-system. For example, I am wondering if restricting broadcasts to a select group of “sister hosts” would reduce excessive messages, or if I could make p dynamically adapt to each host’s current demand. The final data of our p-experiments will be a very helpful guide for future development.

Closing notes

This project continues what my advisor, Prof. Sam Thomas, started during his grad school program. I was given a mostly-complete emulator and packet traces to start working with. In the first weeks, I spent time debugging the emulator and making sure it performed as expected. I found and fixed issues with the disjoint addressing (how the CAPULET emulator decides which virtual address ranges represent which host) and scheduling (how the CAPULET emulator decides which trace/host progresses next). A major challenge was figuring out how to normalize the “current timestamp” of each host as the starting timestamps and timestamp densities both varied significantly. I also adapted the emulator so that each host could run a unique workload. The original emulator had it so that each host would run the same trace file.

On a more personal note, I am very grateful that I got to experience this new side of computer science. It was amazing to see just how well-connected the computer architecture community is when I attended ISCA this summer. I would also like to thank my labmates Arsene Laurent and Vadym Musiienko, and my now-graduated labmate Stevie Kim, who was a role model not only in academics but also in Oldenborg’s Japanese hall. And of course, special thanks to Prof. Thomas for this incredible opportunity and support he provided, both academic and moral.