Cross-VM Side-Channel Defense Lab
When two tenants share a CPU, a bug in the silicon can let one read the other's secrets through the cache or the CPU buffers — no network, no malware, just microarchitecture. This lab walks the real classes — L1TF / Foreshadow, MDS, Spectre, Meltdown — and asks the question a platform team actually faces: which mitigations close this channel, and which just cost you throughput? Close every channel, over-kill nothing.
The real job. More noise, a tighter clock.
Close the channel, keep the throughput
You run the hypervisor platform. Each round names a real microarchitectural side channel between co-tenant VMs — L1TF / Foreshadow, MDS, Spectre, Meltdown. Enable the mitigations that actually close that channel — and only those. Leave a needed control off and the channel stays open; switch on a control the threat does not need and you have burned performance for nothing. A round clears only on an exact match. Finish under par for a speed bonus.
What this lab is
- A free, browser-based lab on closing microarchitectural side channels BETWEEN virtual machines that share a CPU — the cross-VM leak, not a single-host bug.
- Each round names a real class — L1TF / Foreshadow (CVE-2018-3646), MDS (RIDL / Fallout / ZombieLoad), Spectre v2, Meltdown — and you enable the mitigations that close that specific channel.
- You are scored on closing the channel WITHOUT over-killing performance: leave a needed control off and it still leaks; switch on a control the threat does not need and you have burned throughput for nothing.
- The hard lesson is the trade-off: core scheduling vs. disabling SMT, L1D flush vs. MD_CLEAR, when a dedicated host is the clean answer, and why memory encryption or KPTI is the wrong tool for a cross-VM cache channel.
- Fully client-side — no uploads, no account, nothing sent anywhere; after each round you see why the right control set is right.
Frequently asked questions
What is the Cross-VM Side-Channel Defense Lab?
A free, in-browser exercise where you play the hypervisor platform team. Each round presents a real transient-execution or microarchitectural side channel between co-tenant VMs — L1TF/Foreshadow, MDS, Spectre v2, Meltdown — and a menu of controls (microcode and hypervisor patch, L1D cache flush on VM entry, MDS buffer clearing, branch-prediction barriers, core scheduling, disabling SMT per-tenant or fleet-wide, moving a tenant to a dedicated host, plus deliberately wrong tools). You enable the mitigations that close that channel at the minimum necessary performance cost.
How is it scored?
Each round has one defensible minimum-sufficient control set. A round clears only on an exact match: every needed mitigation enabled and nothing extra. Leaving a needed control off (the channel still leaks) and switching on a control the threat does not need (wasted throughput) are both penalised, because over-mitigation that costs performance is its own failure. Finish under par for a speed bonus and a higher grade.
Why does disabling hyperthreading matter for these bugs?
L1TF and MDS leak through resources that hyperthread (SMT) siblings share on a physical core — the L1 data cache and the internal store/load/fill buffers. Flushing those structures handles the residue left across VM switches, but a sibling running at the same time can still sample them, so you also need to stop a hostile sibling from sharing the core: either core scheduling (keep siblings in one trust domain and keep the throughput) or disabling SMT (stronger, but a real performance cost). Choosing between them per scenario is the core skill the lab drills.
Does it exploit or test my hardware?
No. Nothing runs on your CPU, nothing is uploaded, and no microcode is read. The scenarios are authored from the public, established facts of each vulnerability class, and the lab runs entirely in your browser with no account and no install. It is a decision drill, not a scanner.