My Favorites


Please to see your favorites.

  • Bookmark
  • Email Document
  • Printer Friendly
  • Favorite
  • Rating:

Security Vulnerability: "Meltdown" and "Spectre" - Hypervisor Information.

This document (7022514) is provided subject to the disclaimer at the end of this document.


SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 11


With the discovery and announcement of the "Meltdown" and "Spectre" vulnerabilities on speculative execution paths within CPUs (see TID 7022512 for details) it is important to understand the exposure and mitigation steps available in SUSE environments.

As disclosed it is possible to maliciously leverage the speculative execution capabilities of modern CPUs to read memory typically restricted to kernel space. On a single, bare-metal machine, this allows for user space process to access and read kernel space memory (note: this vulnerability does not allow a user space process to write kernel space memory.). On a machine that is running as a hypervisor with one or more virtual machines (guests), the situation is more complex:


SUSE provides both Xen and KVM hypervisors as part of the SUSE Linux Enterprise product offerings. While the architecture of both hypervisors differ significantly, the risks of this speculative execution vulnerability are more dependent upon the virtualization mode of the guests rather than the hypervisor of choice.

There are essentially two virtualization modes for virtual machines :
  1. Fully Virtual mode (also known as a Hardware Virtual Machine), including the performance optimized Xen PVH mode. We subsume both as "HVM" in this document.
  2. Para-Virtual (PV) mode
The KVM hypervisor only supports HVM mode, while the Xen hypervisor supports both HVM and PV modes.

Mitigating the risks of accessing privileged memory within a virtual machine is similar to mitigating risks on bare-metal. Kernel updates should be applied to prevent user-space applications from exploiting the vulnerabilities. The greater risk with virtualized environments is the possibility of exploiting the vulnerability to attack the hypervisor itself and/or other guests.

The potential attack options and possible mitigations from a guest against the hypervisor and/or other guests looks like this:

KVM (only HVM)
XEN HVM only
XEN PV (at least one PV guest)
Variant 1 / "Spectre"
Host must be updated
Vulnerable, patches under development
Vulnerable, patches under development
Variant 2 / "Spectre"Host must be updatedHost must be updatedHost must be updated
Variant 3 / "Meltdown"
Not vulnerable
Not vulnerableHost must be updated

1.For KVM hosts, the existing patches for Kernel and QEMU must be applied to prevent vulnerability. Guest kernel patches should also be applied, but failure to update a guest kernel will not allow the guest to access memory on a patched host. Unpatched guests will remain vulnerable within the memory confines of the guest itself.

2. In KVM HVM environments, the guest kernel should be patched to prevent in-guest vulnerabilities. When running on a patched KVM host, an unpatched guest does not have the ability to access memory of the KVM host, or other guests running on the host.

3. In Xen HVM environments the address space accessible to virtual machines is isolated from the host and restricted to the memory allocated to that specific guest. In this environment, vulnerability variant 3 ("Meltdown"), cannot be used to access memory on the host - or memory allocated to other machines running on the same host. However, vulnerability variants #1 and #2 ("Spectre") may be exploitable.

4. In PV environments (Xen only), the guest and the hypervisor share the address space. From the hypervisor's perspective, the guest kernel runs as a user space process in a low privilege level, and the hypervisor runs at the highest privilege level. In this environment, the speculative execution vulnerability can be used from within a guest to gain access to all memory visible to the hypervisor - this includes memory allocated to other PV guests. 
Note: 32bit PV guests are unable to exploit the variant 3 (“Meltdown”) vulnerability as they cannot address the higher memory addresses used by the hypervisor.



To mitigate the risk of these vulnerabilities within a physical or virtual machine, SUSE is releasing updated kernels which should be deployed to all environments. In addition, some hardware platforms require microcode updates which add CPU flags associated with branch prediction. (See TID 7022512 for additional information on microcode update requirements.)

In addition to an updated kernel, KVM environments require updated QEMU and libvirt packages which mitigate Spectre by passing new branch prediction related CPU flags to virtual machines. These new CPU features may be automatically provided to libvirt managed guests (if not overridden through custom CPU configurations), but will require manual command line additions if calling qemu directly. (For additional background, see QEMU 2.11.1 and making use of Spectre/Meltdown mitigation for KVM guests).

Meltdown mitigation in Xen environments is available through updated Xen hypervisor packages which restrict mappings of hypervisor memory to specific regions while 64-bit PV guests run. This approach (patching the hypervisor) mitigates Meltdown with no changes required within 64-bit PV guests. In-machine Meltdown mitigation for 32-bit PV guests does require an updated kernel within the guest.

Spectre v2 mitigation in Xen environments is available through updated Xen hypervisor packages which both utilize branch prediction control, and pass support for branch prediction control to guests (through CPU flags). Patching the hypervisor is sufficient to restrict guests from exploiting Spectre v2 to attack the host (and other guests). However, guests require an updated kernel to prevent the vulnerability within the virtual machine itself.

Spectre v1 is currently a theoretical vulnerability under Xen.
Development efforts are ongoing, and patches will be released as the risks are identified and mitigated.

Additional Note :
SUSE advises to upgrade all SLE based virtual machines, also when they are deployed on virtualisation platforms other than Xen/KVM detailed here.

Additional Information

Additional steps and reading

Another method of mitigating Meltdown is to convert existing 64-bit Xen PV guests to HVM guests. The steps required for this process are described in the SUSE Virtualization Best Practices Guide

Windows guests:

Windows guests run in HVM mode and therefore cannot exploit the variant 3 ("Meltdown") vulnerability to gain access to hypervisor address space. However, KVM hosts must be patched to prevent Windows guests from using variants 1 and 2 ("Spectre") against the hypervisor.
Windows guests themselves should also be patched to prevent in-guest exploits using any of the possible variants. (Contact Microsoft to obtain patches specific to the version of Windows in use.) SUSE's Virtual Machine Driver Pack (VMDP) paravirtual drivers do not play a role in either mitigating or contributing to these vulnerabilities.


This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7022514
  • Creation Date:04-JAN-18
  • Modified Date:21-FEB-18
    • SUSESUSE Linux Enterprise Server

Did this document solve your problem? Provide Feedback

< Back to Support Search

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center