The linked articles state the testing was done with the mitigations provided in the latest kernel enabled. It does not say that the microcode updates were applied during the testing.
Also there was significant reduced performance when hyperthreading was disabled as required to fully mitigate the threat of the vulnerabilities. If the microcode update changes the behavoir of hyperthreading in order to fully mitigate the vulnerabilities without having to completely disable it then there is a chance these changes effect the performance benefit of hyperthreading.
Given Intel's anti-benchmark license clause without evidence otherwise I assume it is not just a chance but a strong likelihood that the performance benefits are significantly impacted.
All the recent microcode patches to fix CPU security flaws have caused performance degradation, so it's fair to mention that people have been upset about this in the past (anecdotally, I know first-hand that people have disabled the patches because it's started to break software that has significant timeouts -- and they were obviously not happy that this was necessary).
It's also (somewhat) fair to assume that this patch would also affect performance until proven otherwise, and Intel changing their license to disallow sharing comparative performance tests doesn't give me much faith that I'm wrong in that assumption.
For the lazy: "If looking at the geometric mean for the tests run today, the Intel systems all saw about 16% lower performance out-of-the-box now with these default mitigations and obviously even lower if disabling Hyper Threading for maximum security. The two AMD systems tested saw a 3% performance hit with the default mitigations. While there are minor differences between the systems to consider, the mitigation impact is enough to draw the Core i7 8700K much closer to the Ryzen 7 2700X and the Core i9 7980XE to the Threadripper 2990WX."
Not looking good for Intel at the moment. It should also be noted that there's believable rumors that the mitigations are not fully effective unless hyperthreading is disabled.
Their tests disabled hyperthreading on Intel due to the security concerns and also on AMD on speculation that security concerns might arise in the future (if I read everything correctly).
"Red Hat’s internal performance testing of a worst-case microbenchmark showed a significant slowdown. However, more realistic applications that utilize vector gathering showed only low single-digit percentage slowdowns."
The performance impact of the microcode mitigation is limited to applications that use the gather instructions provided by Intel Advanced Vector Extensions (AVX2 and AVX-512) and the CLWB instruction. Actual performance impact will depend on how heavily an application uses those instructions. Red Hat’s internal performance testing of a worst-case microbenchmark showed a significant slowdown. However, more realistic applications that utilize vector gathering showed only low single-digit percentage slowdowns.
If the user decides to disable the mitigation after doing a thorough risk analysis (for example the system isn’t multi-tenant and doesn’t execute untrusted code), the user can disable the mitigation. After applying the microcode and kernel updates, the user can disable the mitigation by adding gather_data_samping=off to the kernel command line.Alternatively, to disable all CPU speculative execution mitigations, including GDS, use mitigations=off.
According to https://plus.google.com/+jwildeboer/posts/jj6a9JUaovP Google was deploying a retpoline-based mitigation in production in September. Seems likely that existed _before_ any thought of microcode fixes. I wonder if, based on working with Skylake and newer chips only at the time, Intel thought the microcode version was going to be a performance alternative to retpoline instead of it being the other way around.
It's also crazy to my mind. The reality is these various issues are all having potentially significant impacts on performance -- and it's not just the microcode related changes, but also the kernel changes, etc. It is kind of ridiculous to require everyone to do their own testing and not allow basic numbers to be published.
I also find it fascinating in that in theory your BIOS update can include these changes.. does this anti benchmark license apply if you reflash a new BIOS or just buy a new motherboard with the new bios and then use the same type of CPU to compare?
Makes me want to look at some BIOS and motherboard EULAs now...
Indeed. In order to protect against MDS on Intel chips, you need to disable hyperthreading and apply microcode and OS updates which have their own additional performance penalties on top of that.
You know you are misrepresenting the issue here. The current batch of vulnerabilities does not affect AMD except for the fact that the OS patches affect all cpus, vulnerable or not. Needing to disable hyperthreading on Intel CPUSs is the catastrophic situation I’m referring to... up to 40% loss of performance in thread intensive tasks.
> There are also Spectre fixes landing in kernels. E.g. Linux 4.14.14 added initial retpoline support:
Which has its own performance drawbacks, but the microcode update itself has even more. And you need the microcode update for Broadwell and newer for retpolines to work.
> 8/14/18 – Updated: As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also known as Foreshadow-NG) CVE 2018-3620, and L1 Terminal Fault – VMM (also known as Foreshadow-NG) CVE 2018-3646, due to our hardware paging architecture protections. We are advising customers running AMD EPYC™ processors in their data centers, including in virtualized environments, to not implement Foreshadow-related software mitigations for their AMD platforms.
For those on AMD platforms, how do you disable software mitigations for Foreshadow? Is this automatically done by browsers, operating systems and hypervisors?
The article says that disabling hyper-threading is a worst case scenario, but I don't think it is.
Intel themselves said [1] "Intel is not recommending that Intel® HT be disabled, and it’s important to understand that doing so does not alone provide protection against MDS."
From the screenshot of the Intel documented linked:
The increased latency ... has a small positive performance impact of 1-2% on highly threaded applications.
Making an instruction more than 10x slower overall, for a 1-2% gain (who wants to bet it's some "industry standard" benchmark...?) in a very specific situation sounds like a textbook example of premature microoptimisation. Of course they don't want to give the impression that they severely slowed things down, but the wording of the last sentence is quite amusing: "some performance loss"? More like "a lot". It reminds me of what they said about the Spectre/Meltdown workarounds.
But that doesn't mean you necessarily get to keep the affected feature - the only 'work-around' might be to disable it. Consider TSX on Haswell and Broadwell, where Intel had to disable the whole feature because of a bug. And of course there was the 486 FP bug which couldn't be fixed by any kind of microcode update.
If Intel had to completely disable hyperthreading in Skylake and Kabylake that would make the premium anyone paid for i5 vs i7 worthless.
It's interesting at least to consider just how much performance is degraded by these hardware bugs for certain workloads. While Octane is 1.40x, the average is 1.12x. And this is the i9 9900k, which has partial hardware mitigations, so speedup is better for older chips.
But mitigations=on doesn't even give full protection from ZombieLoad attacks.. if you want full coverage you need to disable hyper-threading, which kills performance. This caused a big debate among linux devs, but keep-HT won out.
So, disabling mitigations is not a good idea for work or critical workloads. But the chance someone compromises the average computer with one of these hardware bugs is probably the same probability that two equal UUIDs are ever generated.
PC overclockers move mountains trying to eek out half-percentage perf gains. Why not flip a flag for 12%?
Also there was significant reduced performance when hyperthreading was disabled as required to fully mitigate the threat of the vulnerabilities. If the microcode update changes the behavoir of hyperthreading in order to fully mitigate the vulnerabilities without having to completely disable it then there is a chance these changes effect the performance benefit of hyperthreading.
Given Intel's anti-benchmark license clause without evidence otherwise I assume it is not just a chance but a strong likelihood that the performance benefits are significantly impacted.
reply