Dynamic Process Isolation: Research by Cloudflare and TU Graz

When CPU "Tells" Become a Tenant-Isolation Problem

Spectre-class attacks exploit a fundamental property of modern CPUs: speculative execution leaves observable traces in timing behavior. These traces are the hardware equivalent of a poker player's involuntary "tell." For multi-tenant compute platforms, the question is not whether such tells exist—they always do—but whether an attacker can observe them reliably enough to extract secrets.

Cloudflare's Workers runtime takes an unusual approach to this problem. Rather than isolating every tenant in its own process or VM, Workers relies on isolates running many tenants per OS process. That design choice rules out the kernel-level address-space separation that other platforms depend on. It also means the standard playbook for Spectre mitigation—microcode patches, kernel hardening, process isolation—is not available as a default posture.

To validate the security of this model, Cloudflare partnered with researchers at Graz University of Technology (TU Graz), a group with deep history in this area: they co-discovered Spectre and subsequently found NetSpectre, ZombieLoad, Fallout, and related bugs. The collaboration produced a paper (available on arXiv) covering both a practical attack against the Workers environment and a new defense, Dynamic Process Isolation, which is now running in production.

Building a Working Attack

The first phase of the research was an attempt to construct a real Spectre variant 1 attack against Workers, despite the platform's existing mitigations. The Workers Runtime already prevents tenants from measuring their own execution time and blocks other nondeterministic behaviors, like multithreading, that could substitute for a local timer. These defenses eliminate the most convenient timing channels.

There is, however, one unavoidable loophole: Workers can communicate with external services. A remote time server is a timing source no runtime can fully suppress. Remote timing is inherently noisier than a local performance counter, but amplification techniques—repeating the attack many times and aggregating results statistically—can overcome that noise.

The team was able to demonstrate a working Spectre variant 1 attack that leaked memory at 120 bits per hour. That is slow compared to attacks on other platforms, but still fast enough to be a security concern in principle.

Importantly, the demonstrated rate was achieved under ideal conditions:

• The "remote" time server was running on the same physical machine, avoiding network latency and jitter.
• The test machine had no other load. Production machines handle hundreds or thousands of concurrent requests, adding significant noise to any timing measurement.
• The attack showed it could read some bits, not that it could locate and extract targeted secrets. Finding interesting data would likely require reading many thousands of bits first.

In real-world conditions, these factors would slow an attack to the point of impracticality—memory contents change frequently, and the Workers Runtime restarts all processes at least weekly during code updates. But relying on this argument alone was not a posture Cloudflare was comfortable with.

Dynamic Process Isolation

The second phase of the research produced a concrete defense: Dynamic Process Isolation. The system, described in Cloudflare's earlier security-model post and now fully deployed in production, uses hardware performance counters to identify Workers whose execution patterns resemble an ongoing Spectre attack. When detected, the Worker is moved into its own OS process before it can leak meaningful data.

A key design insight is that the detector does not need to be perfect. Benign Workers continue to function normally even inside an isolated process, so false positives are tolerable as long as they are relatively rare. That tolerance is what made a working classifier possible where prior efforts had stalled.

The implemented detector is based on branch misprediction counts. Spectre variant 1 attacks—the fastest and simplest variant—work by poisoning the CPU's branch predictor to trigger speculative execution of attacker-controlled code. In the Workers environment, such an attack must execute a loop of repeated mispredictions to accumulate enough statistical signal to overcome the noise floor. Those mispredictions show up clearly in hardware performance counters.

An attacker could attempt to evade detection by spreading out trials over a longer time period, but doing so slows the attack by orders of magnitude—which is precisely the defensive goal. Other Spectre variants were not addressed with separate detectors because they either produce much lower leak bandwidth or are already effectively mitigated by existing runtime defenses.

The defense was validated against the team's own attack as well as several Spectre proofs of concept; it caught all of them. The false-positive rate is low enough for production: out of many thousands of Workers running on the platform, roughly 20 are falsely flagged as attacks at any given time. Full technical details are in the paper on arXiv.