Spectre/Meltdown/L1TF/MDS Mitigation Costs on an Intel Dual Core and HT Laptop | Hacker News Reader

MDS Mitigation Costs on an Intel Dual Core and HT Laptop

phoronix.com

132 pointsmonort51 comments

From a purely non-scientific standpoint my Latitude E7470 performance is below an acceptable threshold now.

FWIW: I haven't done any benchmarks - This is purely anecdotal!

I use VS 2017 / 2019 and the performance is definitely taken a noticeable hit since the last BIOS update.

Opening projects is slow but once they're open the processor is pegged for longer and when using intellisense the process is pegged for longer now too. It's at the point where I looked to replace it even though it was fine up until Jan/Feb this year.

I tried backing out the BIOS update but it failed so I am stuck with it now.

I even bought a NVMe SSD which helped with IO a bit, and upped the RAM to 16GB but the processor is a huge bottleneck now.

It is bad enough that I even had a Surface Book 2 15" for a week to test it and its performance is rotten as well so I returned it

My desktop with an 8700K O/C to 5GHz hasn't had a BIOS update since early 2018 (I think) and is instantaneous for most things: needless to say, I have no intention of updating it.

This is bad for Intel... really bad imo.

Edit: Added the NVMe and RAM bit.

> This is bad for Intel... really bad imo.

Certainly very bad for Intel's customers and partners, but is there any evidence that it's bad for Intel?

Are they offering refunds?

Is there a class action lawsuit likely to inflict significant damage?

Any sign Intel is losing market share?

Are they dropping prices to maintain share?

If anything, Intel's fuckups are actually good for Intel. Customers must now buy more Intel cores to make up for all the compute lost due to their defects.

> Any sign Intel is losing market share?

Purely anecdotal but I just upgraded and consolidated 2 of my home-servers, and for me there was no doubt AMD was the right choice this time around.

All other enthusiasts I know also consider AMD only, and even consider that alone reason enough to build a new rig.

At work though we have a deal/partnership with Lenovo, so I can’t get AMD even if I threaten to quit.

So for now I’m stuck with 4 core CPUs at work, like it’s still 2010.

If you are using 1809/1803 builds of windows, they are noticebly slower due random background crap consuming all ram and cpu. 1903 is more responsive.

For azure workloads, patched server past 04.2019 see less cpu busy time for me.

On older CPUs the specter mitigations <2019 have a significant performance impact.

Other things I've noticed. The new ssms built on newer .net framework is significantly faster (gui) at everything.

I also saw a measurable drop in my full rebuild times. As I do not run any untrusted code on that machine, I disabled all mitigations. There I use a dedicated browser for work related and NoScript for personal so I felt safe with this trade-off. Beyond javascript desktop machines should only be running trusted code.

You do not need to downgrade your BIOS. You can regain all of your performance on the OS level. You can use this tool on windows[1] or edit the registry. On linux just add this to your grub.cfg.

    noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off

[1] https://www.grc.com/inspectre.htm

InSpectre only disables part of the mitigations. Another part is microcode update via BIOS or OS updates, another is binary updates containing workarounds like retpoline.

I may have changed some addition registry settings from the documents over at:

https://support.microsoft.com/en-us/help/4073119/protect-aga...

According to the powershell app

    PS> Get-SpeculationControlSettings

All mitigations are disabled. No need to do anything in BIOS.

Hiw do you get lost performance which is done by hardware back by using software? If HT is disabled at BIOS/UEFI level, how is software bypassing that low level block?

Someone made a "Never AMD" promise in purchasing, so this has pushed up lifecycles on, without exaggeration, all of our hardware by at least two years. The mobile and servers are most affected.

Worst is we support several thousand Macs, most mobile, and after I saw syscall performance choke after High Sierra, especially on apfs, I suggested we ask Apple to buy back or credit us for the loss in expected performance and lifetime.

Instead we froze purchasing on all but high end models and pushed out the replacement timeline waiting for Intel's 9-series, which was supposed to have hardware mitigation.

Now we know that even the 9-series are susceptible.

The SMT patch was pushed out last week, and we're going to have some really interesting conversations in the coming weeks.

Mr Jobs did a deal with the devil to put Intel-only across the product lines, before the iPhone. Now we get this unexpected penalty due to monoculture. Apple can stop bean-counting their cash hoard and start the long process of making amends, else F-U from this commentator

If it had been practical to keep with the PPC line Mac users today would have the same problems, seeing as how POWER CPUs suffer from both Meltdown and Spectre: https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili... This theoretical analysis says G4 and up ones look worryingly vulnerable to Spectre: http://tenfourfox.blogspot.com/2018/01/more-about-spectre-an... Current Freescale/NXP PowerPC designs are vulnerable to Spectre: https://lkml.org/lkml/2018/12/27/98

This may be a vendor issue: I have a fully-patched Mac and while there are regressions in benchmarks it’s never noticeable in normal usage.

Can you please add details? Which Mac exactly? And which benchmarks have been observably slower?

I am pondering an iMac Pro and since it's gonna be a huge investment, I am trying to gather some information and see if its Xeon-W 2195 (18 cores) CPU will be heavily hit by the mitigations.

For most processing tasks like render, the effect will be negligible. Syscall heavy workloads we saw dip up to 50% on all pre-NVMe models with under 4 cores in both the U and HQ series. The practical effect was up to 10 minute logins for new users and glacial access times on models prior to 2017.

We have 6 mid spec'd iMac Pros ($8-11,000/pc), and unless it's being purchased for you, they're a hard product to justify.

With the same budget, I usually recommend building a 1-2U half rack node for compute and getting an LG OLED or Flanders Scientific display if you're doing anything VFX related. For half the expense, you can get equivalent or better specs and invest more where you actually need it.

We buy Macs mostly to remote into other machines built to do the work. It's more economical and much less frustrating.

Thank you. If that's okay with you, I have a few more questions and notes:

- For the moment I am not considering return-of-investment at all, or how pricey the iMac Pro is in general. I know it is more expensive than a competing Linux-based Xeon solution with a pro display (though I didn't believe the difference to be that huge as 50%!).

- You mentioned the performance penalties on pre-NVMe models with <4 cores. But what about the hit on the NVMe and >4 core models?

- I am not gonna do anything VFX related for now but I like having the option if I change focus in the future. Currently I am a programmer who wants to branch out to data science and, in general, analysis of big data sets (and to work on large parallel workloads like CPU multicore + GPU CUDA at the same time). I feel the 18 cores plus the huge L caches of the Xeon W-2195 will be of huge benefit -- but I could be wrong.

- Additionally, I am sick of Linux' brittleness and would just like to use a Mac. I could probably setup a particular Linux to never fail to boot after an update but I have to admit I gave up on that years ago. Linux just seems to acquire bloat over time until one day an update bricks it -- and I don't want to look after it anymore.

- Can you clarify why Macs are more frustrating in your day work? Your statement to me seems loaded with a context I don't have.

- I saw one reviewer claiming the 14 and 18 core variants to be a waste due to the ECC RAM having only 4 parallel channels. Do you have an opinion or observations on that front?

---

TL;DR: I don't care about the price since I am gonna do a lot of parallel programming where the extra cores' bonus should be very impactful, I am after a very solid machine that doesn't brick after an update (like many Linus distros do), and the NVMe SSD, the 18-core Xeon CPU and the tons of ECC RAM will help in my future endeavours a lot. I don't care about the world-class display (a normal 5K retina display would be just fine) so my money there wouldn't be that well spent but oh well, not gonna lose sleep over it.

Is the iMac Pro a good work machine with these caveats, how do you think?

> Context switching on this Core i7 Broadwell CPU takes seven times longer since these mitigations.

Wow. This is of course a laptop, but anything remotely IO intensive is going to seriously suffer. Does anyone know the context switch delta for desktop and server processors?

Would love to see similar in-depth analyses for Windows and MacOS. 25% perf loss in everyday work is a lot.

Does the new Windows 10 sandbox feature help mitigate Meltdown/MDS?

Spectre/Meltdown is a serious problem, but they matter only in shared environments (virtual hosting with multiple accounts per physical machine).

Why the mitigations are even on by default, if the problem doesn’t exist for dedicated single user environments? (desktops/laptops/dedicated server hardware with no code from other users running).

P.S. https://make-linux-fast-again.com/

Why the mitigations are even on by default, if the problem doesn’t exist for dedicated single user environments? (desktops/laptops/dedicated server hardware with no code from other users running).

Most desktops and laptops run a boatload of untrusted code in the form of JavaScript.

How about enabling mitigations in Javascript engines?

There aren't such mitigations to enable. There aren't even purely software kernel-level mitiations.

> There aren't even purely software kernel-level mitiations.

Some are there, otherwise they couldn't be disabled in Linux kernel for faster performance. Which means that they could be enabled on demand.

Some are there, yes, but they're insufficient to provide security. You need both them, and the microcode changes, and to disable HT. I'm not sure what if anything the software changes do alone, they may mitigate some of the attacks, but not all of them.

why do you think you control that?

apple tries, and even then people already managed to run code via pdf engines; on android it's at least more clear you have no control.

You probably have apps in your phone runnig rigth now that ship with their own JS engine for advertising purposes. Do you expect them to have all the necessary safeguards?

Apple did just that in Safari on macOS.

Apple attempted to do that (I believe it was the Google security team’s MDS writeup that referred to it as a “Herculean effort” on the WebKit team’s part), but even they fell short.

The position that all of the browser vendors have landed on at this point is that mitigating this class of attacks in the browser is simply not possible.

> ...but even they fell short.

Can you please elaborate? Did these effort fail completely or is it that if you use your browser a certain way then you can never be protected? (Which implies that using it another way would be safe.)

per the v8 team, efforts to fully secure the JS JIT engine are simply infeasible against some Spectre class attacks:

> Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler.

You talking about the Update they released some days ago? Or those who are several months old?

Apple released a new one for the newest vulnerability so they didn’t have to reduce the performance of macOS by ~30%.

I’m talking about the Chrome v8 team’s white paper on why they are giving up on trying to mitigate Spectre class attacks in software, which mentions, among other issues:

Apple released an update with some mitigations, but they are by no means perfect, and their message is that if you want to truly be safe, either don’t run JS, or disable hyperthreading.

None of these have ben shown to work with a real-world exploit in JS. There is just too much noise going on.

I'm getting so tired over how oveblown this is getting I was thinking of laying down a $1k bet if anybody will take me up on it, but I dont't think anybody would because it likely isnt possible.

Most of the hype seems to be drive by some Intel gotcha hate.

Here's a JS speculative read example straight from the original meltdown paper turned into a PoC checker: https://terjanq.github.io/meltdown-checker/app.js I accept PayPal ;-)

(Of course this depend on your definition of a "real world exploit", but this does show that you can cross boundaries of a type system.)

You know exactly what you are looking for at that exact address, without nothing else running and polluting the cache, and you are given an extended amount of time to attack.

"you can cross boundaries of a type system" is not even close. In no world could this cod be used to gather useful data on a running system. You are literally just reading from an array you had setup.

It is well known in the academic literature that attacks "mitigated" by "there's too much noise, you'll have to try too many times, you can attack it in the lab but not on a real machine" are not mitigated at all. See for instance https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf .

A practical case where you have an extended amount of time to attack are when you're an ad in a background tab of a website with interesting credentials.

> P.S. https://make-linux-fast-again.com/

I like this website because, like its namesake, it promotes a simplistic solution to a symptom of an underlying problem, as if the symptom were itself the problem, in a manner that appeals to those who believe that a just world only has simple problems with simple solutions, and with no discussion of unintended consequences and serious security risks and no consideration of why those who have actually studied the problem in depth advocate different, more complicated solutions.

It does exist in single user environments. What about a desktop/phone that runs untrusted code? e.g. every browser that supports JavaScript.

Yes, and this code is contained within the Javascript engine. Mitigations could be enabled only there.

Disabling HT can't be done per-process. Since per-frame browser processes need to be protected from one another, you can't even run two browser processes on the same core in HT. And scheduling a browser process while leaving the second HT slot on the same core empty is even slower than turning HT off.

Somebody please explain to me why ripping out the JS JIT wouldn't work.

In the most recent discussion of this it was reported that is no longer an easy option with Firefox: https://news.ycombinator.com/item?id=20012750 There's also a general impression that would be too slow for many web pages, and that comment noted it took minutes for logins using JavaScript cryptography to execute.

It seems to me that most people will be willing to pay for slower js as opposed to an overall slower system.

Does it even need to be slower? Almost every single website out there is not a javascript app and so side channel attacks can be mitigated by simply having an rlimit-style CPU time limit after say a user action on a tab.

Browsers rely on kernel/hardware mitigations. Google people even claimed it's impossible to fully mitigate those vulnerabilities in existing Javascript implementation in Chrome.

It's the job of the OS to make sure one process can't read the memory of another process. What you're saying is that should now be the responsibility of the JavaScript engine as well as the OS.

Is there a way to do the same for windows?

De we even have a Proof of concept for the MDS attacks (one that doesn't require other thread to be writing the same data over and over in a loop)?

So much of this seems driven by Intel hate, and while hardware manufacturers should work on mitigation, it shouldn't be done at the expense of performance, especially for machines that don't run untrusted code (even then, I'm not sure it should be done unless the cost is extremely minimal).

JavaScript/WASM is being used as a bogey man, when the overwhelming evidence is that it just isnt possible to exploit the browser with enough consistency to make it work when not assisted. The meltdown POC was more a "look at this neat thing I an do if I set everything up perfectly" - set up to such an artificial extent that it wasn't even applicable to any computer system.

The the one MDS attack I saw required the target to repeatedly write the same byte of memory in loop while being attacked. This isn't going to happen. These MDS attacks at best seem to be able to pick fairly random bytes, and they can only do it while the data they are snooping on is in the load/store buffer, so they can't even run the number of times required to exfiltrate the data consistently.

I haven't seen a single piece of code that will, for example, grap SSH keys from a running ssh program using one of these attacks. From Javascript in a browser? LOL.

While these are very cool and interesting, they arent anything to be worried about, especially if you don't run a cloud service. Oh, but right, Intel hate.

The Intel hate is really misdirected. The entire industry had an incorrect mental model of what process isolation required. All that an x86 CPU promises is that you will get a page fault if you try to access privileged memory. That’s it, and it’s not sufficient for process isolation in the face of malicious code. JavaScript/WASM VMs assumed more or less the same thing. So long as you can catch any out-of-bound array reads or the like, you have a safe “sandbox.” Again, that assumption was insufficient. It wasn’t just Intel and JavaScript developers either. Entire bodies of research were dedicated to techniques that likely would be vulnerable to these sorts of attacks. For example, the idea that you could do away with CPU memory protection if you ran everything in a managed language that makes it impossible to access arbitrary memory.

What you’re seeing as a paradigm shift in what kinds of process isolation are required for modern computing.

While it's true that speculation as a whole needs to be revisited, Intel is impacted to a much greater extent because they designed their hardware to speculate beyond permission barriers as a matter of routine. AMD did not [0] and consequently is affected only by the most general attacks on speculation, e.g., Spectre. As far as I understand, AMD chips are not impacted by Meltdown or any of the MDS attacks.

It'd be great to see Michael run the same benchmarks against an AMD chip that has all relevant mitigations enabled and compare the performance loss. I'd ballpark that AMD chips may have lost ~10% overall, whereas we see here that Intel chips have lost ~25%.

[0] https://www.amd.com/system/files/documents/security-whitepap...

The Intel hate is somewhat consequentialist. Software was written under a security assumption that wasn't true, the alternative code is slower.

Whose fault it is and the ramifications for the relative performance between different processor designs are separate matters, and people understandably aren't going to favor the vendor with the larger performance loss.

Yep. Practically speaking, it's mostly not worth worrying about. You might be able to read a few bytes every second, assuming perfect conditions (minimal context switching, etc.) It doesn't keep me up at night. But, our computers are going to be running slower now... "just in case."

Reply on news.ycombinator.com