I am still shocked at how little repercussions Intel has actually faced for this fisco. This must have cost companies like AWS millions of dollars in lost capacity/early upgrades--why have they not made a serious effort to get these issues under control and why are they not rapidly losing market share to AMD and Arm?
It takes time. Look closely and you will see that some cloud providers are sending out patches for things such as AMD-specific KVM code. Maybe they will not even ever reach feature parity in their offerings, but at least we can understand that interested customers exist, and it is surely sending signals to Intel.
I would think that would actually benefit companies like AWS. Patches for the bug causes applications to run slower, because of that their customers will be forced to use bigger instances and bigger instances cost more.
I suppose only loss for AWS would be if someone decides to move back to own data center because of that, bit I don't think this would cause that.
Why would that be the case? AWS makes no guarantees about the performance of their instances. If everything gets slower, the most likely thing that happens is high-scale customers need a correspondingly higher number of servers to handle their load.
Not only were there few repercussions for Intel, their CEO and some on his team faced few repercussions too.
What amazed me is how Intel execs avoided insider trading charges from the SEC when they sold their own Intel shares, knowing of the problems themselves, but before it was public knowledge.
The Intel vulnerabilities are a matter of national security across the world. If you can use a known exploit to take complete root access at a hardware level, just by running some Network requests on the local network - imagine what a foreign government could do if they wanted.
Because a system is secure as long as somebody doesn't break it. If tomorrow someone comes with an algorithm that can factor a prime number in polynomial time RSA will be useless basically, but since then we consider it secure.
Beside that, all these vulnerabilities comes from optimizations done by the CPU. The only reliable way to avoid them is not to have the optimizations to start with, and that is what mitigations do.
It's the choice of the user to choose if he wants or not the mitigations, I personally have `mitigations=off` on my machines because I think that the security threat is not so big for my workflow.
I can't speak for everyone who's ever used an Intel CPU, but Intel's certainly lost my tiny fraction of market share to AMD, at least for desktops (AMD laptops with solid specs seem to be rather unfortunately rare); switched from Intel + Nvidia to AMD + AMD when I built my latest rig, and haven't looked back.
Granted, in my case it was less about CPU security issues (some - though certainly not all - of which also impacted AMD and ARM CPUs, from what I understand) and more about AMD getting me way better bang for my buck (and also, because I wanted to try out a Threadripper and my God am I glad I did), but still.
I recently brought back to life a PC that a friend was about to throw away. It has an Intel i7 3820 CPU and running latest Ubuntu. Here are my results from Geekbench 5.0.2 Tryout for Linux x86 (64-bit) before and after the "mitigations=off":
mitigations on score:
865 Single-Core Score
2624 Multi-Core Score
mitigations off score:
912 Single-Core Score
3995 Multi-Core Score
Big thanks for making the website. I stumbled upon it a few days ago and I'm pretty happy that somebody pointed my attention towards this.
The parameter list could be even reduced to fewer elements as mitigations=off covers nopti, nospectre_v1, nospectre_v2, l1tf=off, nospec_store_bypass_disable and mds=off.[1]
Thank you for that website. As I disable mitigations on all my personal hardware, this saved me a bit of time when this whole thing started and has served as a nice quick reference since.
For a local workstation user not doing anything sensitive etc I don’t see why you wouldn’t do this. Be smart. Be clean online. And enjoy the full power of your box. A server though, especially one that will be targeted, should take the performance hit and get patched.
There really just needs to be a good way to run your browser in a horrible jail. Someone just needs to sell an arm on a USB stick that you run v8 on for chrome and nothing else.
Destroying the performance of the entire machine to enable the ability to run JS seems a bit over-zealous.
Those exist and they are called chrome sticks. They are also available in laptop format, called Chromebooks. Also, they are available in small form factor box format, known as chromeboxes
I wish they included some level of benchmark for the performance gain. In practice, how much of a difference would that make? Also a short summary of what those mitigations protect against would be great.
This way the reader could make an informed decision: do I want to sacrifice X to get Y?
Difference depends very much on actual workload. For example, I have a small server with mostly CPU-bound programs running, where the mitigations do not noticeably slow down anything, but a simple "xz -l large_iso_file" takes 20 minutes without mitigations=off, but only 2 minutes with.
I've read that it's possible to exploit meltdown or spectre just with javascript. Apparely it's now patched with most browsers.
Other than js, am I right to think it's still a difficult vulnerability to exploit since you need to execute code on a target machine? It seems to be bad news for cloud techs, but not for users.
Lucky for me, I never got to patch for Spectre or Meltdown in the BIOS upgrades for my Razer Blade because they only support Windows 10 as a BIOS upgrade option so you can have a GUI experience for what could be done with a bin file on a USB.
So... what is the worse case scenario if you decide to disable these mitigations? What precausions one can take to be relatively safe while turning these off?
If/when someone finds a way around the timer patch in your web browser (or if your browser doesn't have the patch yet for some weird reason), a website running javascript for long enough can extract kernel secrets and AES keys, a password manager's entire database, any application's authentication token and pretty much anything else in memory.
Executing such an attack is difficult and unreliable, but in my opinion this also means that casting a wide net might be worth it for the attacker instead of only using the exploit kit to target specific computers.
If you run any software in a virtual machine or docker app, this boundary is easily crossed. If you run any application whose supply chain might be attacked (for example, one of the million javascript files in an electron app), such an app can get root on your system through any sandboxing and virtualisation.
In general, these kinds of attacks are cross-process information leaks and sandbox escapes. The attack vector is untrusted code running on your system, of which the by far most common and most potentially malicious is javascript when you use a web browser.
So the worst case scenario? You visit a website with some attacker-controlled javascript, and it successfully picks up information leaks from your password manager allowing it to obtain all your passwords.
I'm not sure how realistic that attack is. I know that for some of these vulnerabilities attacks from javascript were shown to be possible, but I'm not sure what the target information was in that case.
I have a c.2016 Intel development machine. I never log in at the console or use any GUI, it runs command line only Fedora Linux and apart from that it only ever runs code that I myself have written. Because I use it for compiling and testing I need it to run as fast as possible.
Over the past few years it has really slowed down. I got some (not nearly all) of the performance back by using some of the command line options shown here. I'm going to try the whole command line later today and do some actual before and after testing.
But IMO this is the kind of situation where turning off the mitigations makes sense.
So as a somewhat unconcerned user, I've been disabling some kernel mitigation since more or less when these horrors were first revealed, and when I could remember/be bothered after a kernel upgrade.
But I'm on an AMD CPU not intel.
I'm very curious to hear what knowledgeable folks here could tell me about performance gains on AMD (1950x) from these or any other similar switches.
There are some benchmarks of mitigation impact on Phoronix [1]. These benchmarks are only for mitigation sensitive workloads so real world impact will be lower.
Could someone knowledge create a subset of these for AMD Zen? I have some compute-only servers in my garage for which I don't care about mitigations, but do care about performance.
I don't have /etc/sysconfig/grub on Manjaro. Is it /etc/default/grub?
Should I add the line as specified in the article if my CPU is as old as Core 2 Duo? Will it make any difference? Won't it render the system unbootable?
Would be great if this could be done for Windows (mitigations=off). I’d be happy to reboot to a mode where I have 3% better perf. I’d easily do it every time I wanted to play any game where I’m CPU bound
You can turn mitigations off for Spectre and Meltdown by using the GRC InSpectre program from Gibson Research. The tool's main purpose is to display if your system is patched but it also allows you to turn them off. I never tried it to see if it actually works though. Windows might turn them back on for all I know.
My understanding was that "mitigations=off" is a shortcut for "disable all spectre/meltdown changes that cost me performance", at least on a recent kernel.
As explained on the site, yes, but if you are running an older kernel you need to use the individual flags instead, and since the kernel safely ignores any flags it doesn't recognize, the full string works for everyone and doesn't do any harm. (Other than turning mitigations off, ofc...)
That's the thing. On old kernels you have to disable each one separately, on new kernels you can do either that or mitigations=off. If you want to make sure you disable everything on old kernels and disable potential new options on new kernels without going into details - you can use the line provided.
[+] [-] morpheuskafka|6 years ago|reply
[+] [-] bonzini|6 years ago|reply
[+] [-] takeda|6 years ago|reply
I suppose only loss for AWS would be if someone decides to move back to own data center because of that, bit I don't think this would cause that.
[+] [-] Godel_unicode|6 years ago|reply
[+] [-] RachelF|6 years ago|reply
What amazed me is how Intel execs avoided insider trading charges from the SEC when they sold their own Intel shares, knowing of the problems themselves, but before it was public knowledge.
[+] [-] devwastaken|6 years ago|reply
[+] [-] alerighi|6 years ago|reply
Beside that, all these vulnerabilities comes from optimizations done by the CPU. The only reliable way to avoid them is not to have the optimizations to start with, and that is what mitigations do.
It's the choice of the user to choose if he wants or not the mitigations, I personally have `mitigations=off` on my machines because I think that the security threat is not so big for my workflow.
[+] [-] yellowapple|6 years ago|reply
Granted, in my case it was less about CPU security issues (some - though certainly not all - of which also impacted AMD and ARM CPUs, from what I understand) and more about AMD getting me way better bang for my buck (and also, because I wanted to try out a Threadripper and my God am I glad I did), but still.
[+] [-] gameswithgo|6 years ago|reply
[+] [-] earenndil|6 years ago|reply
[+] [-] perch56|6 years ago|reply
mitigations on score: 865 Single-Core Score 2624 Multi-Core Score
mitigations off score: 912 Single-Core Score 3995 Multi-Core Score
[+] [-] jcelerier|6 years ago|reply
[+] [-] jupblb|6 years ago|reply
The parameter list could be even reduced to fewer elements as mitigations=off covers nopti, nospectre_v1, nospectre_v2, l1tf=off, nospec_store_bypass_disable and mds=off.[1]
[1] https://github.com/torvalds/linux/blob/master/Documentation/...
[+] [-] GrayShade|6 years ago|reply
[+] [-] keldaris|6 years ago|reply
[+] [-] kim0|6 years ago|reply
[+] [-] ngcc_hk|6 years ago|reply
[+] [-] tapia|6 years ago|reply
[+] [-] gigatexal|6 years ago|reply
[+] [-] askthrowaway|6 years ago|reply
here are the results:
mitigations on score: 980 Single-Core Score 2008 Multi-Core Score
mitigations off score: 976 Single-Core Score 2741 Multi-Core Score
links before: https://browser.geekbench.com/v5/cpu/376453 after: https://browser.geekbench.com/v5/cpu/376504
[+] [-] jwlake|6 years ago|reply
Destroying the performance of the entire machine to enable the ability to run JS seems a bit over-zealous.
[+] [-] dmitrygr|6 years ago|reply
[+] [-] trollied|6 years ago|reply
Sounds like the old days with X11.
export DISPLAY=win:0.0
[+] [-] vbezhenar|6 years ago|reply
[+] [-] Ecco|6 years ago|reply
This way the reader could make an informed decision: do I want to sacrifice X to get Y?
[+] [-] pferde|6 years ago|reply
[+] [-] pantalaimon|6 years ago|reply
Older hardware is worse off
https://www.phoronix.com/scan.php?page=article&item=sandy-fx...
[+] [-] jokoon|6 years ago|reply
Other than js, am I right to think it's still a difficult vulnerability to exploit since you need to execute code on a target machine? It seems to be bad news for cloud techs, but not for users.
[+] [-] Neil44|6 years ago|reply
https://www.grc.com/inspectre.htm
[+] [-] abhijitparida|6 years ago|reply
Wholesome.
[+] [-] toastal|6 years ago|reply
[+] [-] xaduha|6 years ago|reply
EDIT: depends on the distro
[+] [-] sytelus|6 years ago|reply
[+] [-] jeroenhd|6 years ago|reply
Executing such an attack is difficult and unreliable, but in my opinion this also means that casting a wide net might be worth it for the attacker instead of only using the exploit kit to target specific computers.
If you run any software in a virtual machine or docker app, this boundary is easily crossed. If you run any application whose supply chain might be attacked (for example, one of the million javascript files in an electron app), such an app can get root on your system through any sandboxing and virtualisation.
Edit: obviously, this is a worst case scenario.
[+] [-] ekimekim|6 years ago|reply
So the worst case scenario? You visit a website with some attacker-controlled javascript, and it successfully picks up information leaks from your password manager allowing it to obtain all your passwords.
I'm not sure how realistic that attack is. I know that for some of these vulnerabilities attacks from javascript were shown to be possible, but I'm not sure what the target information was in that case.
[+] [-] rwmj|6 years ago|reply
Over the past few years it has really slowed down. I got some (not nearly all) of the performance back by using some of the command line options shown here. I'm going to try the whole command line later today and do some actual before and after testing.
But IMO this is the kind of situation where turning off the mitigations makes sense.
[+] [-] ttctciyf|6 years ago|reply
But I'm on an AMD CPU not intel.
I'm very curious to hear what knowledgeable folks here could tell me about performance gains on AMD (1950x) from these or any other similar switches.
[+] [-] hrgiger|6 years ago|reply
before: https://browser.geekbench.com/v5/cpu/381062
another before: https://browser.geekbench.com/v5/cpu/381122
after with mitigations off: https://browser.geekbench.com/v5/cpu/381082
I believe there is almost no difference (unless my bios hardened something like this that I am not aware off: https://www.asus.com/us/support/FAQ/1035323/)
If one needs those extra ~200 point I think he might already ensured that no extra app running and he is using cpu isolation
[+] [-] vorticalbox|6 years ago|reply
[+] [-] 0xQSL|6 years ago|reply
[1] https://www.phoronix.com/scan.php?page=article&item=amd-zen2...
[+] [-] m0zg|6 years ago|reply
[+] [-] andrewcchen|6 years ago|reply
[+] [-] ig0r0|6 years ago|reply
mitigations on score: 719 Single-Core Score 1438 Multi-Core Score
mitigations off score: 679 Single-Core Score 1418 Multi-Core Score
Running Ubuntu 18.04.3 LTS with i5-4300 U on a T440s.
Any ideas why? Makes no sense to me.
[+] [-] qwerty456127|6 years ago|reply
Should I add the line as specified in the article if my CPU is as old as Core 2 Duo? Will it make any difference? Won't it render the system unbootable?
[+] [-] alkonaut|6 years ago|reply
[+] [-] Santosh83|6 years ago|reply
[+] [-] thg|6 years ago|reply
[+] [-] hannob|6 years ago|reply
My understanding was that "mitigations=off" is a shortcut for "disable all spectre/meltdown changes that cost me performance", at least on a recent kernel.
[+] [-] Tuna-Fish|6 years ago|reply
[+] [-] viraptor|6 years ago|reply