#speculative execution

A newly discovered side-channel attack dubbed VMScape is raising alarms across the cybersecurity and cloud infrastructure community. Developed by researchers at ETH Zurich, VMScape can break the long-trusted isolation between virtual machines (VMs) and their hypervisors on modern AMD and Intel CPUs—posing a serious risk to multi-tenant cloud environments.

What Is VMScape?

VMScape is a Spectre-style speculative execution attack that enables a malicious VM to steal sensitive data—such as cryptographic keys—from an unmodified QEMU hypervisor process. Unlike previous attacks, VMScape bypasses existing Spectre mitigations and doesn’t require compromising the host itself. A threat actor could, in theory, rent a VM from a cloud provider and exfiltrate data from the hypervisor or adjacent VMs.

Who Is Affected

Researchers found the attack affects:

• AMD CPUs from Zen 1 through Zen 5

• Intel CPUs up to “Coffee Lake”

(Newer Intel “Raptor Cove” and “Gracemont” cores are not affected.)

This widespread impact is especially concerning given how central virtualization is to today’s cloud infrastructure.

How VMScape Works

VMScape exploits incomplete isolation of branch prediction units (BPUs) in modern CPUs. While BPUs were designed to mitigate speculative execution attacks, ETH Zurich discovered that guest VMs can still influence the host’s indirect branch prediction through shared structures such as:

• Branch Target Buffer (BTB)

• Indirect Branch Predictor / Indirect Target Array

• Branch History Buffer (BHB)

Using a Spectre-BTI (Branch Target Injection) attack, VMScape misguides QEMU into speculatively executing a disclosure gadget. This leaks sensitive data into shared reload buffers, which the attacker can then retrieve via a FLUSH+RELOAD cache side channel.

Researchers achieved:

• 32 bytes/second leakage rate

• 98.7% byte-level accuracy

• Extraction of a 4KB secret in ~128 seconds (or ~13 minutes including ASLR bypass)

Why It Matters

Virtualization underpins almost every public and private cloud platform. Breaking guest-host isolation undermines the core trust model of cloud computing. While VMScape requires advanced skills and extended execution time, it demonstrates that hardware-assisted isolation is still vulnerable to speculative execution leaks—even with mitigations enabled.

Vendor & Open-Source Response

The ETH Zurich team disclosed VMScape to AMD and Intel on June 7, 2025, under CVE-2025-40300.

• AMD issued a security bulletin acknowledging the issue.

• Linux kernel developers released a patch adding an Indirect Branch Prediction Barrier (IBPB) on VMEXIT to flush BPUs when switching from guest to host. Researchers report minimal performance impact from the mitigation on common workloads.

Defending Against VMScape

Security teams managing virtualization or cloud infrastructure should:

• Apply the latest kernel and hypervisor patches as soon as available.

• Monitor CPU vendor security advisories (AMD, Intel) for updates.

• Harden multi-tenant environments by isolating sensitive workloads where possible.

• Use hardware with improved branch prediction isolation (newer Intel cores or future AMD CPUs).

Key Takeaway

(This was our actual conversation over imessage, edited to minimize my interjections)

- ok so anyways let’s start with the architecture vs hardware bit

- i would broadly say that computer architecture is the study of how you assemble hardware and software together to make a computer function as efficiently/performantly as possible

- in practice, there’s a tight feedback loop between hardware design, computer architecture, and software

- computer architects say “we could make X run 50% faster if you built hardware Y”, and then hardware designers work with computer architects to implement Y

- in some cases, software engineers will make code that takes advantage of the new functions that computer architects implemented

- other times, the changes are transparent to the software engineers, and what the computer architects and hardware deigners did just makes their code 50% more efficient without the software engineers making any changes

- with regards to these bugs, they both take advantage of a technique called “speculative execution”

- so, do you have a basic mental model for a processor?

- ok a really basic mental model is this:

- you have a processor and memory

- the processor runs on a clock

- each time the clock ticks, the processor reads an instruction from memory

- and then it executes that instruction

- that instruction might be “load data at address X from memory” or “add X and Y and store as Z” or “write Z to address X in memory”

- that’s our simple processor: each cycle, it executes exactly 1 instruction

- so, we don’t build processors like that in practice

- we build our processors to match that model in function, but the implementation doesn’t match that model

- [me] - Since it in reality many instructions are being executed at the same time, it’s not a 1-to-1 function in practice?

- yeah that’s the general idea, but let’s explore why that is in the first place

- the fundamental problem with our basic processor is that it has to do one whole instruction per cycle

- current processors typically run somewhere in the 2-3GHz range, which means that a cycle is 1/3 of a nanosecond

- which is not really all that much time

- to deal with this, we do something called “pipelining”

- we take the hardware that implements each instruction and instead of doing all the work in one cycle

- we might do 1/5 of the work per cycle and do 5 cycles of work at the same time

- so it still looks like we’re doing one instruction per cycle, but we’re really doing 5 instructions at once

- [me] - I’m not sure what i meant by 1-to-1 now. Since many instructions are happening simultaneously, 1 cycle only executes part of the instruction?

- [me] - Eg for “add X and Y and store as Z”

- [me] - X + Y is one part

- [me] - designate as Z is another

- [me] - then write Z to memory another?

- yeah that is pretty accurate

- here, “one to one” means one instruction starts per cycle, and one instruction ends

- so that pipelining concept is where stuff starts getting funny

- pipelining is great because we can now run at a 5x higher frequency

- but

- that only is true if we can “keep the pipeline full”

- let’s say that one of those instructions is “IF X == 1, THEN run code A, ELSE run code B”

- we call that a branch

- [me] - Aha, i see the visual! --<

- haha good! i was wondering whether i should explain it or not. ok so

- if we have a branch, we can’t run the code after the branch until we figure out which fork of the branch we’re taking

- and if we’ve got the branch, we typically won’t resolve which direction we’re branching until we’ve gotten all the way to the end of the pipeline

- so we’ll have several empty cycles in the pipeline where we can’t execute any instructions

- we call these “no-ops” (no operation) or stalls

- obviously, you want to have as few as is possible

- [me] - is the keeping the pipeline full a hardware thing?

- how so?

- [me] - I dont see why the pipeline has to be full to retain the frequency.

- oh ha yeah good question. so there’s a few things

- even if we don’t run an instruction that cycle, we still consume power that cycle

- and that’s become a big issue over time

- like, one of my favorite slides ever was a projection of power density (watts emitted divided by the surface area of the processor) extrapolating out from 2009

- and it was something like, by 2015, processors would have a heat density equivalent to the surface of the sun

- which is obviously not so great

- it is hard to cool the surface of the sun

- [me] - ahahahah!!

- but more importantly, if we stall, then we’re doing less work that cycle

- e.g. if we stall 20% of the time, then in every 5 cycles, we only complete 4 instructions so we’re 20% slower than the ideal

- so to eliminate stalls, we have this idea called “speculative execution”

- and that’s where these bugs come from

- the basic idea is: we’re going to guess which branch of the fork we take, and we’re going to run that fork, and if it turns out that we were wrong, we’re going to undo the work that we did and then run the correct branch

- oh also an important bit of context

- real world processors arent 5 stages

- they’re typically at minimum 20 stages

- and processors are typically also what we call “superscalar”, which means that they have multiple pipelines in parallel

- so if we have 4 “functional units” (what we call the “multiple pipelines” in a superscalar processor), and a 20 stage pipeline, and we don’t resolve the branch until the 20th cycle of the pipeline, then a branch actually stalls us for the equivalent of 80 cycles

- so the penalty of a branch is pretty huge, and branches are everywhere, all the time, you can’t escape them

- THERE’S NO STOPPING THEM

- IT IS LIKE A CRASHING WAVE

- [me] - I am imagining this exponential growth in functions

- oh lol it gets much worse

- this whole speculative execution thing requires a bunch of crazy shit. fortunately, i don’t think we really need to get into the details of how speculative execution is implemented

- but the high bit is that you have a branch predictor, which computes some heuristics like “when i’ve seen this branch before, how common is it that i take fork A vs fork B?” or “when i saw this branch last, did I take A or B?”

- yeah and miraculously, these are pretty good in practice

- ok so the big thing that the processor does if it tries to execute speculatively and fails is that it makes sure that nothing got incorrectly overwritten in memory

- if the prediction was bad, we make sure we didn’t write anything

- what the bigger of the two bugs exploits

- is that while we make sure we didn’t overwrite anything in memory

- we don’t also make sure that we didn’t keep data that we read

- so if we speculated that we were going to take fork A, and fork A reads private data, but then we take fork B instead

- the code in fork B could read the private data accessed by fork A

- that’s the gist of the bug

- [me] - And thats something which could be patched..? Like at an enormously high cost/effort?

- nah

- its like

- “redesign the last 30 years of computer architecture”

ENDNOTE-

more technical papers

this obviously has large implications for everything digital ever.

Speculative Execution in Hadoop

Job Tracker Vs Task Tracker in Hadoop When data is injected for map reduce job in Hadoop, the Job tracker takes care of the job and distributes the task to task tracker. If any one of these task fails then job tracker starts the new task in another data node. Job tracker completely gives up after three times tried. Task tracker can be failed for many reasons including like misconfiguration,…