Blog

Visit often for current news, announcements, and insights.

Performance Implications of the Meltdown and Spectre Fixes

Sergey Maximov

Technology Corner

MeltdownPerformanceSpectreVirtuozzo

Virtuozzo has been releasing fixes for the Meltdown and Spectre vulnerabilities as they become available. An updated summary of our fixes is included below and will be proactively updated here on our blog. There are concerns about potential performance degradation associated with installing these fixes.

Vulnerabilities Summary

CVE-2017-5753
Spectre (Variant 1)
Bounds check bypass.
CPUs utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access.
This vulnerability implies that a constrained code may leak information from the containing code. What is fixed by the kernel patch is the ability of the host userspace to leak data from the host kernel via speculation over bounds check in system calls.
As for the guest code or host applications doing sandboxing and the like web browsers, there is a need for its own fixes.
CVE-2017-5715
Spectre (Variant 2)
Branch target injection.
CPUs utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access.
The full fix requires:
1) The latest Virtuozzo kernel update
2) QEMU update
3) libvirt update
4) Updated microcode
5) All VMs needs to go through full stop/start, it will recreate qemu process, and the virtual machine will use a new processor supporting all the necessary mitigation features.
6) Guest OS update, update sandboxing apps
CVE-2017-5754
Meltdown
Rogue data cache load.
CPUs utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access.
This issue is fixed with the latest Virtuozzo kernel updates.
Guest OS should be updated as well.
CVE-2018-3640
Spectre (Variant 3a)
Rogue system register read.
A local unprivileged attacker could read privileged memory.
Hardware issue to be resolved by the CPU vendor microcode update.
The issue is not planned to be mitigated in software.
CVE-2018-3639
Spectre (Variant 4)
Speculative store bypass.
A local unprivileged attacker could read privileged memory.
To mitigate the vulnerability, both microcode update and software updates are needed. Contact hardware manufacturer to check whether BIOS update for your servers exists and whether it has microcode update that mitigates CVE-2018-3639. Virtuozzo released the software updates.

 

Virtuozzo 6 and Virtuozzo 7 fixes for Meltdown and first two Spectre vulnerabilities are available and this article describes the microcode update procedure. For the previous versions please refer to this post.

Virtuozzo 7 and Virtuozzo 6 kernel and hypervisor fixes for Spectre variant 4 are available here and here.

Performance Implications

Virtuozzo help you assess performance implications, we have provided benchmarking results for Virtuozzo 6 and 7 based on testing we recently conducted. Benchmarking revealed that Meltdown and Spectre Variant 1 fixes have a negligible impact on performance. Benchmarking of Spectre Variant 2 fix has revealed some performance degradation. Review the analysis contained in this post for the latest information. Of course, the degradation depends on the workload. We’ll continue running tests with different workloads and update our blogs regularly to ensure you have the most current information on this issue.

Speculative execution is a performance optimization technique and some fixes are disabling particular optimization. These kernel patches are enabled by default and after the update you might see performance degradation.

Meltdown Variant 3 Fix

Meltdown fix Linux kernel introduced Kernel Page Table Isolation (KPTI). It introduces an additional virtual address space switch between userspace and kernel execution modes and has some performance implications.

Virtuozzo ran a standard vConsolidate1 test to assess performance impact.

Containers performance impact from KPTI is about 2-3%:

Blue graph #1: Virtuozzo 7 containers prior to Meltdown fix (no KPTI)
Yellow graph #2: Virtuozzo 7 containers after Meltdown fix (KPTI enabled)

Virtual Machines (VMs) benchmarking revealed no degradation at all:

Blue graph #1: Virtuozzo 7 hypervisor prior to Meltdown fix (no KPTI)
Grey graph #2: Virtuozzo 7 hypervisor after Meltdown fix (KPTI enabled)

As our benchmarking shows, the impact of applying the Meltdown fix is insignificant. Please note these tests do not apply fixes for a guest OS and guest patching might introduce an additional performance penalty.

Spectre Variant 1 and 2 Fixes

Spectre Variant 1 vulnerability is fixed with the kernel update and it has no performance impact.

Spectre Variat 2 requires both the kernel update and the microcode update. It enables the following CPU features:

  • Indirect Branch Restricted Speculation (ibrs)
  • Indirect Branch Prediction Barriers (ibpb)

These features are required to implement the mitigation solution. As the result we can see 15-20% performance degradation in vConsolidate test on Containers (KPTI is enabled as well):

Blue graph #1: Virtuozzo 7 containers prior to Spectre fix (no KPTI, no IBRS, no IBPB)
Yellow graph #2: Virtuozzo 7 containers after Spectre fix (KPTI, IBRS, IBPB are enabled)

For Virtual Machines the results are better: Spectre mitigation patches resulted in about 10-15% performance degradation:

Blue graph #1: Virtuozzo 7 hypervisor prior to Spectre fix (no KPTI, no IBRS, no IBPB)
Grey graph #2: Virtuozzo 7 hypervisor after Spectre fix (KPTI, IBRS, IBPB are enabled)

Please note: applying the guest patches will probably have additional performance penalty.

 

Future Improvements

First of all if you feel confident your systems are well protected by other means (such as physical isolation and strong access controls/monitoring), you may wish to disable some or all of these kernel patches. We don’t recommend doing it for public VPS/Dedicated services, however in the case of application hosting, where you have full control over applications running and the access rules, it might make sense to disable at least some of the most performance critical patches.

In addition, there are new ideas about mitigating the risk. More Linux Kernel & GCC patches are coming out with potentially less performance implications. GCC compiler patches are not yet in mainline, but we will do our best to adopt them as soon as possible. Once we have the initial results we’ll publish immediately.

It's important to emphasize that the measurements have been performed on a synthetic benchmark, and that the actual degradation the user will experience may vary depending on the workload. If you are facing challenging performance issues please contact our support team for immediate help. We’ll continue running tests with different workloads and atomic operations tests. All new articles will be published as separate blog posts.

1:
vConsolidate test is a performance benchmark; it deploys one or more groups of virtual appliances, which run certain applications working together as a single group (called Consolidation Stack Unit (CSU)). Each server in the group generates output results, such as transactions per second, and the aggregated result is used to compare different virtualization solutions. By increasing the number of CSUs, it is possible to compare how different virtualization solutions behave, which produce more transactions on the same hardware with the same number of CSUs, and which are able to run more tiles effectively (before overall system performance begins to decrease).

Benchmarking setup

KPTI test bench
  • CPU: 24SMP (2S+6C+2T) Intel(R) Xeon(R) CPU E5645 2.4GHz
  • RAM: 128GB DDR3 1600MHz
  • HDD: 5 x 900GB SAS 10K (RAID0)
  • NET: 10G client–server crossover
KPTI+IBRS+IBPB test bench
  • CPU: 64SMP (4S+8C+2T) Intel(R) Xeon(R) CPU E7-4809 v4 2.1GHz
  • RAM: 128GB DDR4 2133MHz
  • HDD: 6 x 450GB SAS 15K (RAID0)
  • NET: 10G client–server crossover
Back