
Spectre/Meltdown/L1TF/MDS Mitigation Costs on an Intel Dual Core and HT Laptop - monort
https://www.phoronix.com/scan.php?page=news_item&px=Spec-Melt-L1TF-MDS-Laptop-Run
======
_Understated_
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.

~~~
slacka
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](https://www.grc.com/inspectre.htm)

~~~
sebazzz
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.

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

[https://support.microsoft.com/en-us/help/4073119/protect-
aga...](https://support.microsoft.com/en-us/help/4073119/protect-against-
speculative-execution-side-channel-vulnerabilities-in)

According to the powershell app

    
    
        PS> Get-SpeculationControlSettings
    

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

------
tompic823
> 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?

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

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

------
atemerev
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/](https://make-linux-fast-again.com/)

~~~
danieldk
_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.

~~~
atemerev
How about enabling mitigations in Javascript engines?

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

~~~
atemerev
> 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.

~~~
danarmak
_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.

------
jnordwick
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.

~~~
rayiner
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.

~~~
cookiecaper
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...](https://www.amd.com/system/files/documents/security-
whitepaper.pdf)

