Microsoft Outlines Performance Impacts of Meltdown and Spectre Patching

Last week, a serious flaw involving Intel processors was detailed and the impact of the remediation techniques are now starting to be better understood. As Microsoft has begun patching its side of the equation and hardware vendors are now shipping out updates to patch their side of the flaw, the real-world performance impact is starting to be felt by customers.

First and foremost, as most know by now, this is a hardware security vulnerability and not something that is the fault of Microsoft. But, seeing as Microsoft is the behind the software running on this impacted chipsets, it has to work with the cards it was dealt to make sure that the end-user is protected.

Because of the seriousness of this vulnerability, not patching to avoid the performance hit is not an option. This is a hardware level design flaw in Intel chips and unfortunately, there is no way to retain the performance state of today after patching to fix the security flaw to protect you from the threats of tomorrow.

It’s important to know that there are three vulnerabilities, two under the Spectre name and one under the Meltdown name as shown in the chart below.

The software and hardware patching impacts older chips (prior to Kabylake and Sklake) at a more noticeable rate than newer silicon which means that Windows 7 and Windows 8.1 users will likely see a more significant impact to their daily operations than those running newer chips. That being said, tasks that involve intensive IO workloads, as well as launching applications, will be impacted and for the end user, this may not be all that noticeable but for the data center, this is likely a different story.

Microsoft is currently running benchmarks and has yet to share the total findings publicly but based on their early tests, they believe that the patch for variant 2 (from the above chart) will have the largest impact on performance.

Here is Microsoft’s guidance on performance impact based on patching for both Spectre and Meltdown vulnerabilities:

• With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, most users will not notice a change because these percentages are reflected in milliseconds.
• With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and Microsoft expects that some users will notice a decrease in system performance.
• With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), Microsoft expects most users to notice a decrease in system performance.
• Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance and balance the security versus performance tradeoff for your environment.

For the end user, running daily tasks like email and web browsing, the impact will be negligible but high-intensity workloads will see performance degradation after the updates are applied for both end-user and enterprise workloads; especially in older chips and when running older versions of Windows.

The more likely scenario of serious performance impact comes into play is in the data center; Windows Server and other applications could have significant performance hits that could interrupt business operations. Even if the impact is only 10ms, when that task is executed 10,000 times per hour, the performance hit becomes a very serious concern. And considering this issue impacts Server running on any silicon, if you are managing a datacenter, you will need to be watching your performance peaks very closely.

But there is a caveat here, if you are only running trusted code, you don’t need to install the microcode updates to patch the CPU. This can be a bit confusing as this only applies if all code meets the ‘trusted code’ qualification and if anything slips past this qualification then you need the microcode updates.

The reason why older CPUs are being impacted more so than newer chips is that of decisions made during the time of development that resulted in things like font rendering taking place in the kernel. The result is more overhead following the patching of these flaws which is the cause of the performance hit post patching. Inevitably, this will sound like a sales pitch to buy new hardware and unfortunately, to get the performance you need for your data center, this may be the only solution for some users.

Because of the serious nature of this vulnerability, it is imperative that you patch your system as soon as possible. Thinking that you should not patch to keep your performance levels at their current state is a reckless approach to managing your environment. As Microsoft releases more benchmarks for the performance hits for patching, I’ll be sure to keep you updated.