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, no patches available
Vulnerable, no patches available
Variant 2 / "Spectre"Host must be updatedVulnerable, no patches availableVulnerable, no patches available
Variant 3 / "Meltdown"
Not vulnerable
Not vulnerableVulnerable, no patches available

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 vulnerability within the memory confirms 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, the vulnerability variants #1 and #2 ("Spectre") may be exploitable.
Development efforts are ongoing, but according to the Xen community ( no hypervisor fix is currently available.

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 this vulnerability, SUSE is releasing updated kernels which should be deployed to all environments (bare-metal, HVM and PV). This updated kernel (in conjunction with updated qemu and Xen packages) prevents user space processes from accessing privileged, kernel space memory.

However, this change is currently insufficient to completely safeguard against exploits in Xen environments. (For example, users with root privileges in a PV domain could easily backrev to an older kernel, or create a kernel module to bypass the safeguards in the patched kernel.)

The Xen Project is aware of this risk and is actively working towards a resolution. Until such a hypervisor-level resolution is available the only way to mitigate these risks is to convert existing PV guests to HVM guests.

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

Until such a hypervisor-level resolution is available, the only way to mitigate these risks is to convert existing PV guests to HVM guests. The steps required for this process are described in the SUSE Virtualization Best Practices Guide

Warning: Converting a PV guest to an HVM guest can result in a VM that fails to boot if not all necessary steps have been taken accordingly. This documentation is relevant for SLE 11 and SLE 12 and Other Linux Operating Systems.

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:09-JAN-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