Dynamic Process Isolation

## Overview

At the conference, speakers Pietro Borrello, Andreas Kogler, and Martin Schwarz from a University of Technology presented on "Dynamic Process Isolation," evaluating the security posture of edge computing platforms like Cloudflare Workers against microarchitectural attacks. Cloudflare Workers serve as edge computing systems deployed between origin servers and clients to intercept and modify HTTP requests (for instance, to gather statistics or inject ads into request bodies). To maintain high performance and eliminate the heavy resource overhead of classical virtualization, these platforms employ **in-process isolation**, running different users' workers and code within the exact same process.

---

## Defensive Preconditions and Assumptions

The speakers explored whether running multiple untrusted workers within a single shared process creates vulnerabilities to Spectre-style attacks. The platform operators implement several defensive preconditions and resource controls designed to obstruct such exploits:

- **Timer Disabling:** Local high-resolution timers are disabled to eliminate the standard mechanisms used to measure microarchitectural timing differences. - **Request Limiting:** Platforms strictly limit both sub-requests and overall outgoing requests that workers can issue. - **Memory Restrictions:** Available memory per worker is constrained. - **Performance Constraints:** Any defensive mechanism or isolation solution deployed to mitigate speculative execution attacks must have very low overhead to avoid compromising the edge platform's high-performance goals.

---

## Cache Side Channels: Flash and Reload

To explain how in-process boundaries can be breached, the presenters walked through foundational cache mechanics and the **Flush+Reload** cache side-channel technique:

1. **CPU Caches & Memory Access:** CPUs rely on caches for low-latency memory access. When an access misses the cache, data must be fetched from DRAM (resulting in a slow access time) and loaded into the cache. Subsequent accesses result in cache hits with significantly faster access times. 2. **Shared Memory Prerequisite:** Flush+Reload assumes an attacker and a victim share physical memory pages (such as shared libraries or memory loaded within the same host process). 3. **Execution Steps:** - **Flush:** The attacker flushes specific shared memory addresses so that the corresponding cache lines are evicted from the CPU cache. - **Victim Execution:** The victim process or worker executes and potentially accesses one of those shared cache lines, reloading it into the cache. - **Reload:** The attacker accesses the memory line again and measures the access latency. A fast access time (cache hit) reveals that the victim accessed that address, leaking information about the victim's execution and internal state.

---

## Spectre and Speculative Execution Foundations

The presenters mapped how Flush+Reload primitives combine with CPU speculation to bypass architectural boundary checks:

- **Attacker Control:** An attacker supplies an index used to read from a data array. Although an explicit boundary check exists (e.g., ensuring `index < 4`), modern CPUs execute instructions ahead of time via branch prediction before the check resolves. - **Secret Access:** Even though architectural logic restricts access to designated victim data and forbids accessing secret keys out-of-bounds, speculative execution still executes the out-of-bounds read transiently. - **Shared Lookup Tables (LUT):** The secret data value retrieved transiently is used as an offset to index into a shared lookup table (`LUT[data]`). This transient memory access alters the cache state of the shared lookup table based on the secret value, establishing the microarchitectural covert channel.