Sharing is leaking: blocking transient-execution attacks with core-gapped confidential VMs

Confidential VMs promise a cloud tenant secrecy even from the hypervisor, but a steady stream of speculative-execution attacks keeps breaking that promise, because the tenant still shares a physical CPU core — and all its speculative machinery — with untrusted code that the hypervisor schedules; this paper (EPFL and Google) proposes core gapping, keeping distrusting code off the same core entirely so the shared microarchitecture that leaks simply is not shared, and shows how a trusted firmware monitor can enforce this without trusting the hypervisor, on Arm hardware, at performance competitive with ordinary VMs.

The argument in one glance

Problem

Confidential VMs promise secrecy from the hypervisor, but speculation keeps leaking it

Cloud providers now offer confidential VMs — on Intel TDX, AMD SEV, and Arm CCA — that encrypt a tenant's memory and take the hypervisor and host software out of the tenant's trusted computing base, so in principle a tenant is protected even against a malicious cloud operator, trusting only the CPU hardware and attested firmware. But that promise has been broken again and again by transient-execution vulnerabilities: the Spectre-family attacks that exploit how modern CPUs speculate and execute out of order, leaking secrets through the microarchitectural state that speculation leaves behind. And confidential VMs are ironically the most exposed, because the untrusted hypervisor still controls scheduling: it can interrupt a guest at just the wrong moment to sample its microarchitectural state, or place an attacker on a sibling hardware thread of the very same physical core as the victim. The root cause is that distrusting parties still share one CPU core, with all its complex speculative machinery, and the party controlling who shares it is the one you do not trust.
What people did

Flush the microarchitectural state and patch each new leak

The standard response is reactive mitigation: when a guest transitions to the untrusted host, have the trusted monitor flush microarchitectural structures — Intel's module flushes branch history, for instance — and as each new transient-execution vulnerability is disclosed, ship a microcode fix or software patch to close it.
Why it fell short

Flushing is costly, incomplete, and always a step behind

Flushing carries an inevitable performance cost, and it only works for microarchitectural structures that the hardware actually exposes to software control — many leaky structures cannot be flushed at all, and the flushes are usually added retroactively, after an attack is discovered. The deeper problem is that this is a treadmill: the vulnerabilities stem from the aggressive speculation and out-of-order execution CPUs use to maximize single-threaded performance, so they keep coming, and the flood shows no sign of stopping. Chasing each new leak with an ad-hoc mitigation is a losing game that leaves confidential VMs perpetually one disclosure away from broken, at real overhead.
This paper's idea

Stop sharing the core, and enforce it without trusting the hypervisor

Core gapping takes a principled route: if distrusting security domains never run on the same physical core, then the shared microarchitectural state that these attacks exploit simply is not shared, removing essentially all same-core side channels and transient-execution vulnerabilities from the guest's trusted computing base. The obstacle is that enforcing "no shared cores" normally requires trusting the hypervisor to schedule that way — and it is untrusted. This paper's insight is to make the already-trusted security monitor firmware enforce it: the monitor, not the hypervisor, decides which cores confidential VMs run on, dedicates cores to them, and routes every exit to the untrusted host onto a different core. The result is software-only, needs no hardware changes, and its Arm prototype performs competitively with ordinary VMs.

Why this problem is worth solving

The attacks in question are not bugs to be fixed once but a structural consequence of how fast CPUs are built.

Transient-execution attacks, beginning with Spectre and Meltdown, exploit the speculative and out-of-order execution that modern processors use to go fast. A CPU guesses which way a branch will go, or runs instructions before it is certain they should execute, and if the guess is wrong it discards the results — but the discarded, transient execution still leaves traces in microarchitectural state: cache lines that were loaded, branch predictors that were trained, buffers that were touched. An attacker who can observe those traces, typically by timing their own accesses, can reconstruct secrets the transient instructions touched. Crucially, this microarchitectural state is shared by whatever runs on the same core, and it is invisible to the normal architectural abstraction, so software cannot simply avoid leaving traces. Because these behaviors are inherent to aggressive single-threaded optimization, new variants keep appearing, and the same features CPUs added for performance are the ones that leak. That is why a defense that closes one variant at a time is always behind, and why a structural fix that removes the sharing itself is so attractive.

The reason confidential VMs are hit hardest is a mismatch between who is trusted and who controls the hardware.

A confidential VM is a cloud guest whose memory is encrypted and whose trusted computing base excludes the hypervisor and host, so a tenant is protected even from a hypervisor-level attacker. Every major architecture now supports this — Arm CCA calls the guest a realm VM, Intel TDX a trust-domain VM, RISC-V CoVE a trusted VM — and they converge on a common design: a hardware-enforced privileged mode runs a small security monitor (Arm’s realm management monitor, Intel’s TDX module) that is attested and trusted by both the host and the guest. Memory can be marked confidential and made inaccessible to the host, and the monitor interposes on every transition between the guest and the host, saving and restoring register state so the host never sees the guest’s. But the hypervisor, though outside the trusted computing base, still controls resource allocation and scheduling — which core a guest runs on, when it is interrupted, what shares its core. So the very party the tenant does not trust decides the physical conditions under which microarchitectural leaks can be set up and amplified, which is exactly what makes transient-execution attacks so potent against confidential VMs, and why enforcing the physical isolation must come from the trusted monitor, not the hypervisor.

What people did before, and where it broke

Flush microarchitectural state on host transitions. Have the trusted monitor scrub structures like branch history when the guest exits to the untrusted host. Where it broke. Flushing costs performance, only covers structures the hardware exposes to software control, cannot flush everything, and is typically added retroactively after a vulnerability is found — so leaks through unflushable or unknown structures remain.
Patch each transient-execution vulnerability as it appears. Ship microcode fixes and software mitigations for each new Spectre-family variant. Where it broke. The vulnerabilities are inherent to speculative, out-of-order execution and keep coming, so this is an endless treadmill with substantial cumulative overhead, always one disclosure behind.
Disable sharing features like hyperthreading. Turn off simultaneous multithreading so sibling threads cannot share a core. Where it broke. It removes only one sharing channel; distrusting code still time-shares a core through context switches, and the untrusted hypervisor still controls that scheduling, so leaks across time-slices and to privileged code persist.
Assume the hypervisor will isolate cores. Rely on scheduling that keeps distrusting domains on separate cores. Where it broke. In a confidential VM the hypervisor is untrusted by definition, so the guest cannot depend on it to implement core isolation — the entity that would enforce the separation is the entity the model excludes from the trusted base.
The gap. No approach both eliminated same-core sharing of microarchitectural state and enforced that separation without trusting the hypervisor. Doing it software-only, by leveraging the already-trusted security monitor to dedicate cores and route host interactions off-core, is what core-gapped confidential VMs provide.

How core-gapped confidential VMs work

Making the trusted monitor keep distrusting code off the same core

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Do not defend the shared microarchitecture — stop sharing it. Every transient-execution defense that flushes state or patches a variant accepts the premise that distrusting code will share a core and tries to scrub what leaks between them, which is costly, incomplete, and perpetually reactive. Core gapping rejects the premise: if two security domains never occupy the same physical core, the caches, branch predictors, and buffers that leak are simply never shared between them, so essentially all same-core side channels and transient-execution vulnerabilities fall out of the guest’s trusted computing base at once, without knowing or flushing any particular structure. Removing an entire class of speculative leaks by construction, rather than mitigating each one after it is found, is the same principled instinct the speculative-load-taming work covered elsewhere on this site pursues, redesigning how execution proceeds so that the microarchitectural traces attackers rely on cannot form, instead of playing whack-a-mole with individual attacks.

Route the host off the core so the untrusted party never shares it either. Keeping other guests off the core is necessary but not sufficient, because a confidential VM also exits to the untrusted hypervisor and host constantly — for hypercalls, interrupts, and device work — and a naive implementation would context-switch to the host on the same core, reintroducing exactly the sharing core gapping was meant to remove. The design’s move is to never context-switch to the host on a dedicated core: instead, the monitor delegates every exit to a remote core via a cross-core remote procedure call, so the host does its work on a different physical core and the guest’s core stays uncontaminated. Avoiding the expensive, sharing-inducing transition to the untrusted host by handling its interactions out-of-band on separate hardware is the same exit-avoidance discipline the exit-less VM-access work covered elsewhere on this site is built on, keeping the guest off the costly path through untrusted privileged code rather than paying for it on every interaction.

Enforce all of this from the one component both sides already trust. The reason this could not be done before is that the natural enforcer of core isolation is the scheduler, and in a confidential VM the scheduler lives in the untrusted hypervisor. The insight is that another component is already trusted and already sits on every guest-host transition: the attested security monitor firmware. By modifying it to constrain which cores a confidential vCPU runs on, to dedicate cores, and to delegate exits off-core, the isolation is enforced by trusted code without extending trust to the hypervisor and without any hardware change. Placing enforcement of an isolation policy in the small, attested, mutually-trusted monitor rather than the large untrusted supervisor is the same trust-minimizing architecture the co-location-attack work covered elsewhere on this site underscores the need for, since it is precisely the shared, adversary-controlled substrate that leaks — and core gapping puts the control of that substrate in trusted hands.

Following a confidential VM through core gapping

Running a guest without ever sharing its core

A trace, from the paper, of how a core-gapped confidential VM runs on Arm CCA, keeping untrusted code off its core and handling exits remotely.

Step 1 of 5

The monitor dedicates a core to the guest

To run a confidential vCPU, the trusted monitor firmware takes a physical host core, marks it dedicated to confidential-VM execution, and constrains the vCPU to run there. The untrusted hypervisor can no longer schedule any other vCPU, or a sibling-thread attacker, onto that core.

On Arm this is done by modifying the trusted firmware and using processor hotplug to bring cores under the monitor's control.

Why it works

Not sharing a core removes the leak by construction. Flushing and patching accept sharing and try to scrub what leaks → but if distrusting domains never share a core, the caches, predictors, and buffers that leak are never shared → so essentially all same-core side channels and transient-execution vulnerabilities leave the guest’s trusted computing base without touching any specific structure.
Routing exits off-core closes the trust-boundary hole. Keeping other guests off the core is not enough because the guest still exits to the untrusted host → but delegating every exit to a remote core via cross-core RPC means the host never runs on the guest’s core → so the isolation holds across the boundary with privileged code, not just between guests.
The trusted monitor can enforce what the hypervisor cannot be trusted to. Core isolation normally depends on the scheduler, which is the untrusted hypervisor → but the attested security monitor already sits on every transition and can constrain and dedicate cores itself → so the policy is enforced by trusted code with no added trust in the hypervisor.
Software-only means it is deployable now. A hardware fix for speculative leakage would take new silicon and years → but core gapping is realized by modifying existing trusted firmware with no hardware changes → so it applies to current and forthcoming confidential-VM platforms directly.
Avoiding sharing can even help performance. One might expect dedicating cores to cost throughput → but not sharing a core also means no cache or branch-predictor pollution from co-tenants → so CPU-intensive workloads can run faster, and the prototype is competitive with ordinary VMs overall.

What it costs (trade-offs and scope)

Dedicating cores changes how capacity is used. Core gapping gives a confidential vCPU a physical core to itself, including its sibling hardware threads, so the provider cannot pack distrusting tenants onto the same core; this can reduce consolidation for some workload mixes even though CPU-intensive workloads benefit from the locality, and it reshapes how a cloud sells and schedules capacity.
Off-core exits add cross-core latency. Delegating every host interaction to a remote core replaces an on-core context switch with a cross-core remote procedure call and inter-processor interrupt, which adds latency to exits; the design mitigates this with fast RPCs that avoid busy-waiting and by minimizing interrupts, but exit-heavy, input-output-bound workloads pay more than compute-bound ones.
It mitigates all-but-one known isolation-breaking vulnerability, not literally everything. Core gapping removes same-core sharing, which covers the vast majority of the transient-execution and CPU-bug attacks that have broken cloud VM isolation, but the paper is careful that it addresses all but one of the known classes; cross-core and other channels outside the same-core model are out of its scope.
It rests on the security monitor being correct and trusted. The whole guarantee moves enforcement into the attested monitor firmware, so the guest’s security now depends on that firmware behaving correctly; this is a smaller and already-trusted base than the hypervisor, but it is still trusted code that must be right, and the design modifies it.
The prototype is Arm CCA on a simulator plus a current Arm platform. The implementation targets Arm CCA by modifying Arm’s trusted firmware, evaluated on a simulator for the forthcoming extensions and on current Arm hardware without confidential-VM support; the paper discusses applying the approach to Intel TDX and RISC-V CoVE, but those are argued rather than built, so cross-platform generality is a design claim.

The evaluation

Protecting a confidential VM from same-core leakage

Property	Flush and patch	Disable hyperthreading
Coverage of same-core transient-execution leaks
Handles the untrusted host on the core
Requires trusting the hypervisor	No, but leaks remain	For scheduling
Needs hardware changes	Often microcode	No
Performance		Loses SMT throughput

From the paper's evaluation. Core-gapped confidential VMs remove same-core side channels and transient-execution vulnerabilities from the guest's trusted computing base with a software-only change to the trusted monitor, enforced without trusting the hypervisor. The Arm prototype performs competitively with ordinary VMs, and the locality from avoiding shared cores can improve performance on CPU-intensive workloads.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

The contribution is a principled, deployable fix for a problem the field had been mitigating reactively: confidential VMs keep leaking through the microarchitectural state they share with untrusted code on the same core, and the untrusted hypervisor, which controls scheduling, can amplify those leaks. Core gapping removes the sharing itself — no distrusting code on the same physical core — which takes essentially all same-core side channels and transient-execution vulnerabilities out of the guest’s trusted computing base, and the key insight is that the already-trusted, attested security monitor can enforce this by dedicating cores and delegating every host exit to a remote core, so no trust is added to the hypervisor and no hardware is changed. The Arm prototype is competitive with ordinary VMs, and avoiding shared cores can even speed up compute-bound workloads. Read that within its scope. Dedicating cores reshapes consolidation and can cost density for some workload mixes; off-core exits add cross-core latency that hurts exit-heavy, IO-bound work more; the guarantee covers all-but-one known same-core class, not every channel; it depends on the monitor firmware being correct; and the prototype is Arm CCA on a simulator and current Arm hardware, with Intel and RISC-V argued rather than built. Within those bounds it is a rare thing in this space: a structural defense that closes an entire class of attacks by design instead of chasing each new one.

Background

Why sharing a CPU is the hard problem of cloud security

It helps to see why so much of cloud security comes back to the fact that tenants share hardware. The economics of cloud computing rest on multiplexing: many customers’ workloads packed onto the same physical machines, even the same cores, to keep utilization high and costs low. That sharing is the whole business model, and it is also the whole attack surface. Two workloads that share a core share the caches, the branch predictors, the execution ports, the speculative machinery — none of which the clean architectural abstraction of a CPU mentions, but all of which carry faint traces of what the other workload did. A determined attacker who can get co-located with a victim can read those traces and extract secrets across a boundary that was supposed to be airtight, which is why a steady stream of research demonstrates cross-tenant leaks through shared microarchitecture. Confidential VMs raised the stakes by promising to protect tenants even from the cloud operator, making these microarchitectural channels the last and most dangerous gap. That world, where an attacker’s ability to share hardware with a victim is the precondition for stealing their data, is the same one the public-cloud co-location-attack work covered elsewhere on this site studies, showing that landing on the same machine as a target is both feasible and dangerous. Core gapping’s answer is to deny the precondition: if the attacker can never share the victim’s core, the shared-hardware channel closes.

If you remember only three things

1. Confidential VMs on Intel TDX, AMD SEV, and Arm CCA aim to remove the hypervisor and host from a cloud tenant's trusted computing base, but a relentless flood of transient-execution attacks (Spectre-family speculative-execution leaks) keeps defeating this, because distrusting parties still share a physical CPU core with all its speculative microarchitectural state, and the untrusted hypervisor controls scheduling so it can amplify leaks by interrupting the guest or co-scheduling an attacker on a sibling hardware thread; flushing state and patching each new variant is costly, incomplete, and perpetually reactive.
2. Core gapping fixes this by construction: if distrusting security domains never run on the same physical core, the shared caches, branch predictors, and buffers that these attacks exploit are simply not shared, removing essentially all same-core side channels and transient-execution vulnerabilities from the guest's trusted computing base. The obstacle is that enforcing "no shared core" normally requires trusting the hypervisor's scheduler, which is untrusted; the paper's insight is to have the already-trusted, attested security monitor firmware enforce it instead — constraining which cores a confidential vCPU runs on, dedicating cores to it, and delegating every VM exit to the untrusted host onto a remote core via fast cross-core RPC so the host never shares the guest's core.
3. The scheme is software-only with no hardware changes and adds no trust in the hypervisor; the Arm CCA prototype (modifying Arm's trusted firmware) performs competitively with ordinary shared-core VMs, and the better cache and predictor locality from not sharing a core can even speed up CPU-intensive workloads. The trade-offs are that dedicating cores reshapes consolidation, off-core exits add cross-core latency that hurts exit-heavy IO-bound workloads, it covers all-but-one known same-core vulnerability class, and it depends on the security monitor firmware being correct, with Intel and RISC-V applicability argued rather than built.

Check yourself

Check your understanding

1. Why are confidential VMs especially vulnerable to transient-execution attacks?
2. What is core gapping, and why does it defeat these attacks structurally?
3. How does the design enforce core gapping without trusting the hypervisor, and handle the guest's need to reach the host?
4. What did the evaluation show, and what are the trade-offs?

Sources

The paper is “Sharing is leaking: blocking transient-execution attacks with core-gapped confidential VMs” by Charly Castes (EPFL and Google) and Andrew Baumann (Google), published at ASPLOS 2024 (Volume 4), DOI 10.1145/3622781.3674190.

This explainer is written from the full text of the authors’ copy of the paper. Everything above comes from the paper’s own sections: the introduction on the repeated transient-execution vulnerabilities and CPU bugs since Spectre and Meltdown that break CPU security isolation, stemming from aggressive speculation and out-of-order execution and showing no sign of stopping; the rise of confidential VMs on AMD SEV-SNP, Intel TDX, and Arm CCA that encrypt guest memory and remove the hypervisor and host from the guest’s trusted computing base, and the irony that they are most at risk because the untrusted hypervisor controls scheduling and can amplify leaks by ill-timed interrupts or by co-scheduling attacker and victim vCPUs on sibling hardware threads of a shared core; the definition of core gapping as isolating distinct security domains on distinct cores, which avoids the vast majority of shared microarchitectural state and mitigates all but one of the known cloud-VM-isolation-breaking vulnerabilities, requiring both that guest vCPUs run on distinct physical cores and that privileged host code run on distinct cores too, with the fundamental limitation that the untrusted hypervisor cannot be relied on to implement it; the convergence of confidential-VM ISA extensions (Arm CCA realm VMs and the realm management monitor, Intel TDX trust-domain VMs and the TDX module, RISC-V CoVE) around a trusted, attested security monitor that interposes on all guest-host transitions and saves and restores register state; the prior mitigation of flushing microarchitectural state on host transitions (such as Intel’s branch-history flush) and its costs and incompleteness; the paper’s design of core-gapped confidential VMs by modifying the trusted firmware to constrain the physical CPUs on which a confidential vCPU is dispatched, dedicate host cores to confidential-VM execution, limit interrupt causes and frequency, and delegate all VM exit events to a remote core via fast cross-core RPCs using inter-processor interrupts rather than busy-waiting; the Arm CCA prototype modifying Arm’s trusted firmware, evaluated on a simulator for the forthcoming extensions and on current Arm hardware; and the performance evaluation showing core-gapped CVMs competitive with shared-core VMs and, thanks to greater locality from avoiding shared cores, sometimes faster on CPU-intensive workloads, together with the discussion of applying the approach to Intel TDX and RISC-V CoVE.