Can you break out of a VM into other VMs, or into the hypervisor with Meltdown?

No, due to the fact that memory is (and has always been) isolated when running in a VM context.

Note this doesn't hold true for paravirtualized (PV) guests, but these are relatively unused and being phased out.

Unlike Meltdown, Spectre can break out of a virtual machine.

Can you break into a VM from a process on the hypervisor with Meltdown?

Yes, a malicious userspace application running on a hypervisor can read memory in any VM hosted on it.

What mitigations are available for Meltdown?

There is only one mitigation necessary and implemented for Meltdown, KPTI (Kernel Page-Table Isolation). KPTI has now been rolled out to all supported Ubuntu releases via security updates.

What is PCID?

PCID (Process-Context Identifier) is a CPU feature which allows tagging of TLB entries so that page table switches don't invalidate the whole cache. This reduces the performance impact of KPTI. Performance is further restored almost to previous states when PCID is used in combination with a more recent CPU feature, INVPCID. PCID and INVPCID were added in Intel's Westmere (2010) and Haswell (2013) CPU microarchitectures respectively.

While PCID support was only included in the upstream 4.14 kernel, it has been backported along with the KPTI patchset as part of the kernel updates in the Meltdown USNs issued on Jan 9.

Virtual machines can't use these optimisations unless the hypervisor exposes the CPU's PCID and INVPCID features. If the VM is running with an updated kernel, KPTI will still be active and the VMs will be secure, but they will experience seriously degraded performance until the hypervisor is updated to expose them.

Is there KPTI support for 32-bit x86, a.k.a. i386?

Not currently. There is a patchset posted upstream by SUSE that may serve as the basis for this support in the future, but for now there is no way to mitigate Meltdown on 32-bit x86 kernels.

For now the recommended workaround is to install a 64-bit kernel with KPTI enabled; this is possible while still running the unmodified 32-bit userspace installation. However, even with KPTI support, a 32-bit x86 kernel cannot use PCID or INVPCID, so the performance impact will be severe.

In virtualized environments, does updating the hypervisor protect guests?

No, guests must upgrade to a kernel with KPTI in order to protect themselves from their own userspace processes.

Vulnerable hypervisors can be used to attack all system memory, including memory owned by VMs. Vulnerable VMs can leak memory between processes within that VM, including between containers. For full protection, both the hypervisor and guest kernels need to be upgraded.


Can Spectre be exploited through a web browser

Yes, it can. Javascript is a known attack vector, and browser sandboxing is insufficient to protect from it. This means that browsing the web with a vulnerable browser can open up an end-user to attack.

While no videos have been published, there has been PoC code published that demonstrates the vulnerabilities, and Tencent have released an online checker that uses a similar approach.

Every major browser vendor had advisories linked in the vulnerability disclosure site and in the context of Ubuntu, Firefox and Chromium have been updated.

Can VMs read memory from the hypervisor, or other VMs running on the same hypervisor with Spectre?

Yes, these exploits are possible with Spectre. As we noted above, hypervisor memory is normally unavailable in VM context, but Spectre works by tricking the CPU executing in hypervisor mode into leaking memory through caches into the VM.

So Spectre indeed allows a VM to read memory which only the hypervisor should have access to, and since the hypervisor kernel has all system memory accessible, attacking the hypervisor kernel effectively provides access to all system memory.

How do the Spectre mitigations work?

Spectre mitigations are a complex topic due to the fact that there are 2 variants (named here SV1 and SV2), 4 different underlying mechanisms being used to mitigate them, and permutations in terms of support across hardware, hypervisor and operating system.

SV1 is mitigated only by patching code sequences found to be vulnerable; static analysis is the mechanism currently being used to find these. This means that many userspace attacks are likely to remain undiscovered.

There are 4 different underlying techniques SV2 mitigations utilize:

  • Indirect Branch Restricted Speculation (IBRS)
  • Indirect Branch Predictor Barrier (IBPB)
  • Single Thread Indirect Branch Predictor (STIBP)
  • Retpoline

Of those, the first 3 are implemented in hardware and require microcode updates to be accessible. They also need to be implemented on both the hypervisor and the guest levels, and the hypervisor needs to expose the features to the guests.


What is retpoline?

Retpoline is a software workaround that mitigates against SV2. This workaround does not require microcode in order to be active; however, it requires that code be recompiled with a compiler enabled with this feature. Recompiling the kernel with this feature is simple, but updating all of userspace is a significant effort, without which protection from speculative userspace attacks needs to rely on the slower hardware-based mitigations.

Does retpoline work on AMD, ARM, and other architectures?

Retpoline is effective on x86 CPUs from Intel and AMD. It's not currently supported on processors from other vendors or of other architectures.

If I run on a hypervisor with retpoline enabled, is my VM protected?

No. Retpoline immunises software that is compiled with it against attacks using Spectre variant 2, but non-retpolined software running on the same system is still vulnerable. A retpolined hypervisor cannot be attacked, but in most cases (depending on how the hypervisor is configured) direct attacks between VMs and from VM processes against VM kernels are still possible. Some clouds prevent attacks between VMs, but it's unlikely that any prevent attacks between processes or against the kernel within a VM.

If I'm using retpoline, do I still need the microcode features and corresponding firmware or hypervisor support?

Yes, for now. A kernel (and hypervisor, if in a VM) using retpoline is sufficient to defend against the existing public Spectre variant 2 attacks, but they leave any un-retpolined userspace code vulnerable. Direct attacks that bypass the kernel are inevitable, so until every piece of code on a system is rebuilt with retpoline the kernel must use microcode-based mitigations to protect userspace.

If I'm not using retpoline, do I need to have all microcode features enabled?

Yes. Updated firmware/microcode (and hypverisor, if in a VM) are required to mitigate Spectre variant 2 on amd64, ppc64el and s390x platforms.

What userspace applications are being updated?

Due to the nature of Spectre, many userspace applications are likely affected. However, we understand that most applications have a reduced attack surface, and have focused our attentions on browsers which are the most important attack vectors and where key exploits were showcased.

As mentioned earlier, Firefox has been updated, now to 58 but originally to 57 in USN 3516: -- the corresponding advisory from Mozilla is at

Chromium is a Universe package, and as such does not receive USNs, but has been updated to version 63, which disabled SharedArrayBuffer support. We are currently awaiting the upstream release of version 64, which will contain broader Spectre mitigations.

SecurityTeam/KnowledgeBase/SpectreAndMeltdown/TechFAQ (last edited 2018-12-04 23:56:04 by tyhicks)