Respond to Meltdown and Spectre

From Xen
Revision as of 18:11, 12 January 2018 by Dunlapg (talk | contribs) (Add "pv shim" solution)

This page is meant to collect practical advice about responding to XSA-254 (also known as the 'Meltdown' and 'Spectre' vulnerabilities).

General introduction

XSA-254 covers information attacks that can leak information in modern superscalar processors. There are three different 'variants', dubbed SP1, SP2, and SP3. SP3 is also known as 'Meltdown', and only affects Intel processors. SP1 and SP2 are known as 'Spectre', and affect all modern superscalar processors (including ARM, AMD, and Intel).

SP1 and SP2 are difficult to exploit. SP3 is trivially easy to exploit.

There are two factors to consider when securing a system against these:

  • Protecting Xen against untrusted guests
  • Protecting guest kernels against guest userspace

Only Intel processors are impacted by SP3. On Intel processors, only 64-bit PV mode guests can attack Xen. Guests running in 32-bit PV mode, HVM mode, and PVH mode cannot attack the hypervisor using SP3. However, in 32-bit PV mode, HVM mode, and PVH mode, guest userspaces can attack guest kernels using SP3; so updating guest kernels is advisable.

Guest kernels running in 64-bit PV mode are not directly vulnerable to attack using SP3, because 64-bit PV guests already run in a KPTI-like mode. However, guest userspace can still use SP3 to attack the hypervisor, which contains guest kernel memory.

Concrete actions

Migrate all untrusted VMs to run in HVM or PVH mode

Most modern kernels can run either in PV or HVM mode. There may be practical other changes which need to take place to convert a PV image into an HVM image; specific examples are listed below.

If you have a PVH-capable hypervisor (Xen 4.10) and a PVH-capable kernel (Linux 4.11), then booting in PVH mode should require the least number of changes.

Another option that will be available soon is "PV Shim" mode. In this mode, a PV guest boots inside a PVH container, with a "shim" hypervisor providing a binary-compatible PV interface. Patches implementing this should be available for Xen versions 4.10, 4.9. and 4.8 in the near future.

Apply all updates to domU kernels as soon as possible

Updates protecting Windows from SP3 are already available. Updates to Linux should be coming through your distribution channels soon.

Minimize dom0's vulnerability to attack

Currently it is only possible to run domain 0 in PV mode. In this mode, the hypervisor can be attacked on Intel processors using SP3, even from user mode.

However, an attacker that can run arbitrary code in domain 0 already has a number of other ways to gain control of the hypervisor. So it is always best practice to minimize the number of services running in domain 0, to reduce the attack surface.

Use PV shim mode for PV guests

If you cannot update your PV guests to HVM or PVH guests, you can use a "PV shim". This shim is a miniature version of Xen designed to run inside an HVM or PVH guest and provide a native PV interface.

NOTE: This will protect your hypervisor from your guest, but it will not protect your guest kernel from your guest userspace, even if you've applied the KPTI patches.

Instructions on how to build and use the shims can be found in the XSA-254 advisory

Be ready to apply SP2 patches when they become available

Patches to mitigate SP2 will be available for Xen in the near future. Be ready to apply these once they are available.

Guest kernels should have patches for SP2 available in the near future as well. Watch your distro for updates to guest operating systems and apply them as soon as possible.

Consider updating to Xen 4.8 or later

A lot of the changes necessary for the PV shim and for the SP2 mitigations rely on architectural changes made in recent versions of Xen. In many cases, backporting solutions (such as the PV shim) to versions of Xen before 4.8 will be very difficult. Updating to a newer version of Xen -- 4.8 or newer, in particular -- will ensure that you have access to the most complete set of updates as soon as possible.

Technical issues upgrading from PV to PVH

Non-partitioned disks

Partitioned disks without an MBR or suitable /boot

Switching from a PV console to an HVM console