Multi-Tenant Guest Isolation Lab
Strangers’ workloads share one host, and none of them trust each other. Every isolation decision is the same trade: density versus isolation. Deduplicate memory with KSM and you hand a tenant a timing side-channel; use a flat shared L2 and everyone sees everyone; share the host kerneland one kernel bug reaches them all; co-schedule untrusted tenants on SMT siblings and L1TF/MDS leak across the core. Make the call on each, and learn why the cheap, simple option is usually the one that lets one tenant into another.
The real job. More noise, a tighter clock.
Design brief
You run a host where mutually untrusting tenants share the hardware. Make each isolation decision. The tempting “density” option is usually the trap.
#1 · Memory
Memory dedup across tenants
The host has KSM (kernel same-page merging) available, which deduplicates identical memory pages across all VMs to reclaim RAM. Tenants do not trust each other.
#2 · Network
Tenant network segmentation
Every tenant's VMs need network access. How do you lay out the virtual network?
#3 · Kernel
The kernel-sharing model
You can run each tenant's workload as containers sharing the host kernel, or as full VMs / microVMs each with their own guest kernel. The tenants are untrusted.
#4 · CPU
Co-scheduling untrusted tenants on cores
The hosts have SMT (hyperthreading) enabled. How should the scheduler place untrusted tenants onto physical cores?
#5 · Storage
Tenant storage layout
How do you provision disk for tenants?
#6 · Trust
The underlying trust assumption
A platform architect argues: "The hypervisor is a hard boundary. Once tenants are in separate VMs, we do not need further isolation controls."
#7 · Placement
Co-locating sensitive and unknown tenants
You have a high-value regulated tenant and a pool of brand-new, unvetted free-tier tenants. Capacity is tight.
#8 · Mobility
Live-migration trust domains
Live migration is enabled. By default any tenant VM can be migrated to any host in the fleet to balance load.
Decisions so far
0/8 answered, 0/8 right.
The through-line
Every decision trades density / convenience against isolation. For untrusted tenants, isolation is the correct default: no shared kernel, no shared dedup, no shared L2, no sibling-thread co-tenancy, no free co-location.
Taking the tempting density option costs an extra bite.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based multi-tenant isolation lab: make the design decisions a host full of mutually untrusting tenants forces — memory, network, kernel model, CPU scheduling, storage, placement and the underlying trust assumption.
- Each round pits density and convenience against isolation: the cheap, simple option (shared L2, host-wide KSM, shared-kernel containers, free co-location) is almost always the one that lets one tenant reach another.
- It drills the real cross-tenant channels: KSM dedup timing leaks, L1TF/MDS across SMT sibling threads, shared-kernel container weakness, and DMA/device remanence from shared passthrough.
- You are scored on correct calls, with an extra penalty for taking the tempting density trap — and after grading each decision explains what the cheap option would have let a hostile tenant do.
- Runs entirely in your browser — no account, no install, nothing sent anywhere.
Frequently asked questions
What is the Multi-Tenant Guest Isolation Lab?
A free, in-browser decision lab set on a host where untrusted tenants share the hardware. You make the isolation choices that matter: whether to run memory dedup (KSM), how to segment the network, whether to share the host kernel or give each tenant its own, how to place tenants on CPU cores, how to provision storage, where to place sensitive workloads, and whether to treat an escape as possible. Each decision scores you against the hardened answer.
Why is the "efficient" option so often wrong?
Because density and isolation pull in opposite directions. Deduplicating memory across tenants saves RAM but creates a timing side-channel; a flat shared L2 is simplest but puts every tenant on one broadcast domain; shared-kernel containers are lightweight but leave every tenant one host-kernel bug from the others; packing sensitive and unvetted tenants together maximises utilisation and maximises blast radius. On an untrusted host the cheap default is usually the insecure one.
Are the side-channels real?
Yes. KSM cross-VM dedup timing, L1TF/Foreshadow and MDS/ZombieLoad leaking across SMT sibling threads, and DMA/device-remanence from reused PCI passthrough are all established, demonstrated classes — they are why cloud providers disable SMT co-tenancy, flush CPU buffers, apply microcode and avoid cross-tenant memory dedup. The lab describes them by class rather than citing CVE numbers.
Who is it for?
Cloud and virtualization platform engineers, SREs building multi-tenant infrastructure, and security leaders who need to reason about where tenant isolation really comes from. It is free and runs entirely client-side.