CloudFlare Workers

Multi-Tenant Scripts in Shared Edge Processes

In edge-computing environments like Cloudflare Workers, multi-tenant scripts within shared processes refers to an architecture where code from thousands of different customers (up to 2,000 distinct tenants) executes inside a single OS process, sharing a single virtual address space [1, 2].

1. Architectural Design & Benefits

• Language-Level Isolation: Rather than placing each tenant inside a separate operating system process or virtual machine, the platform relies on software sandboxing using JavaScript engines like Google V8 isolates [1, 3].
• Performance Density: Eliminating container and OS process isolation boundaries reduces virtualization overhead and context-switching costs [1, 3]. This allows edge providers to achieve high density per server, keeping compute close to users without requiring massive server clusters [1, 3].

2. Security Vulnerabilities (Microarchitectural Side-Channels)

Vector	Impact & Mechanism
Shared Address Space	All worker threads execute within the same host process, placing tenant scripts in a common memory space [2, 4, 5].
Spectre Exploitation	Malicious JS constructs speculative gadgets to bypass software sandboxes and leak co-located tenant secrets [1, 5, 6-8].
Timer Restrictions Bypass	Removing high-res timers is bypassed using remote timing servers paired with signal amplification techniques [2, 8, 9-11].

3. Proposed Solution: Dynamic Process Isolation

• Performance vs. Security Trade-Off: Enforcing process isolation for all scripts introduces massive CPU and memory overhead [3, 7].
• Targeted Migration: Dynamic Process Isolation acts as a hybrid engine monitoring hardware performance counters (HPCs) for branch misprediction anomalies caused by Spectre mistraining [12-16].
• Automated Containment: Benign scripts stay inside the low-latency shared process, while suspicious workloads are instantly migrated into dedicated process sandboxes [12, 13, 17].