A Look At The CPU Security Mitigation Costs Three Years After Spectre/Meltdown

[Jabberwocky]

I don't particularly recommend it, unless you know what you are doing, which includes trusting
your software (this is possible, even with the web), evaluating risk, and needing all the speed of your machine.

Good to know. You seem like a reasonable person, so think of my response as a thought experiment and not some random person trying to criticize you, your choices or procedures.

There are many people with decades of programming experience and top positions at companies who don't fully understand these attacks. I have spoken to people with B.Sc. (Hons.) in CS that still do not understand the attacks despite their credentials. On the other side people with no formal education or at least not CS related and are providing workarounds to the problems or writing pen-tests. The point is: This problem requires years of specialization to understand how this impacts your systems.

In most cases obtaining this specialization is not productive and does not help your business or career so there's little incentive for someone to obtain it. There still are people that are passionate about these problems and enjoy it as a hobby who don't need a financial incentive, yet IMO it's a dying breed. From a philosophical perspective it's not very practical either as a hobby.

Given a (reasonably) safe environment is met, it is a bit wasteful to not use the full speed of your CPU

A safe environment is probably the most difficult part in trying to prevent attacks. If you do a really good job here you could turn off your firewalls, use old firmware that gives your computer even more speed than just turning off kernel options. The problem is that it's extremely challenging to ensure that this environment exists. In my estimation it's cheaper for an individual to buy more and faster computers than to evaluate all the software on a typical system, but it is possible to have are environments where it's the other way around.

The best way IMO to prevent side-channel attacks on faulty hardware without software mitigations is to run trusted software[1] and to prevent or sandbox[2] remote code or even remote data. Meaning don't connect your computer to the internet or if you do make sure there are no vulnerabilities in software that send or receive network requests. In the past if you ran apache via the "www-data" user if someone found an apache exploit then they were limited to that user. That is no longer the case if the attacker is using side-channel attacks. The attacker cannot automatically read your entire FS or simply just copy your SSH keys, they need to wait for you or one of your services to access it before they can read it. This gives attackers much more vectors to infiltrate sensitive parts of a system. This is why side-channel attacks are such a big problem for cloud providers, attackers can skip the first exploit completely. You already have the ability to run code when they sign up and start a non-dedicated instance.

1. How does packages become trusted? Is it because there are no reports of problems, do you trust the individuals who evaluate the packages, or those that originally write the software of those packages?

2. Sandboxes are not impervious to attacks.

for vulnerabilities that have probably waaay less chance to be exploited that to win at the Euromillion lottery.

Sometimes it's some massive 0day exploit other times just a simple script or container that you ran. It does not even have to be malicious, but just needs to be insecure in some regard. In a typical OS and home network configuration how would you know if you have been a target of a side-channel attack? Without this information how do you estimate your risk of getting attacked? Sure not everyone wins the lottery, but we at least know if someone wins.

Again, people have different priorities. I need my Linux work PC to be fast and only install packages from my distro whose packagers I trust.

I agree with this. One should just be very careful of the packages that are installed and used. This could very well either open the door or keep it closed to a side channel attack, given the history of bugs found in various packages.

If someone doesn't care about leaking their information nor do they have information about other people or businesses, by all means turn off the mitigations.

If someone has other people's data or code on their machine, it's better to err on the side of caution. They just might win the lottery on the same day as a few others without knowing.

Sorry for the long reply. I think it's important to understand first and then to choose priorities. I hope it helped in some way.

PS: In theory security to me is about not taking chances. I know it's not always practical. Yet odd things happen... Last month my country's (South African) lottery ended with numbers: 5, 6, 7, 8, 9, and 10. The exact order was 8, 5, 9, 7, 6 and extra powerball 10, still people here lost their minds

[Takla]

It's worth remembering that the mitigations' penalties are not only in terms of CPU performance but also, with some hardware, really serious stability problems. I run old stuff, Core-i5 on Sandy Bridge (LGA 1155). With latest Intel microcode loaded and enabled I found my PCs (different ones running Debian Testing and Windows 10) to be a real nightmare. There were sudden shutdowns, failures to resume from S3 sleep, failure to hibernate, failure to boot reliably, system freezes, higher temps, more fan noise and so on. I disabled the mitigations and my machines returned to their original, rock solid, boring, very quiet, reliable selves. Everything works perfectly again. On the Windows 10 PC 3D gaming on Steam returned to being smooth & reliable instead of jerky and liable to crash without warning. I've also disabled mitigations on my Intel Atom devices. One I use running Win 10 as a TV box (because Netflix annoyingly only allows 720p on Linux but 1080p is fine on Win on the same hardware!) and it was hopeless until I used the inspectre tool from grc.com to disable mitigations. Another Atom device runs a tvheadend server, DVB-T2 tv stick using Debian and yes, I disabled mitigations on that too and it's great.

If anyone can point to definite, verifiable & successful real world attacks on unmitigated x86 PCs I'd be very interested, genuinely, as if it looks serious I have to start saving up many thousands of pounds for much newer hardware. Meanwhile I'm happy with my 2013 powerhouses

[bobbie424242]

No. This is not wise. Don't recommend this to others.

I don't particularly recommend it, unless you know what you are doing, which includes trusting
your software (this is possible, even with the web), evaluating risk, and needing all the speed of your machine.
Given a (reasonably) safe environment is met, it is a bit wasteful to not use the full speed of your CPU
for vulnerabilities that have probably waaay less chance to be exploited that to win at the Euromillion lottery.
Again, people have different priorities. I need my Linux work PC to be fast and only install packages from my distro whose packagers I trust.

[Jabberwocky]

The JS engines are also isolating, and have been compiled to do that on their own.

You're right, this is a major win. We have lost some runtime accuracy, but definitely worth the loss IMO. After all JS is typically used for handling sensitive info opposed to playing games or doing accurate benchmarks/time-measurement.

[Jabberwocky]

Why is that?

It takes time and it's not the top priority right now. Intel is not alone, the same goes for AMD and ARM.

The average customer that is using x86 typically don't care that much about security and are happy with the mitigations that are in place. I don't agree, but it is what it is. Intel's goal is probably just to match AMD's security which it seems like they have accomplished now. They will likely prioritize performance improvements since there's a higher demand for it.

It looks like the Raspberry Pi 4 was vulnerable to SSB until 5 months ago and nobody noticed (or reported) it prior to that. The hardware is still vulnerable but at least the mitigations are applied in the latest updates. There are still some minor kernel problems that needs to be solved in the official Pi kernel (based on 5.4, upstream mainline does not have this problem). I have some concerns about it since I'm running k8s on a Pi4 cluster. It's a hobby project I have limited time to investigate and test. Anyway these problems are expected when you have a small budget and maintain your own kernel and firmware. I don't blame the engineers, they seem to be doing a good job.

The PR team and forum feedback leaves much to be desired.
1) https://www.raspberrypi.org/blog/why...e-or-meltdown/
2) https://www.raspberrypi.org/forums/v...c.php?t=243416

[torsionbar28]

Why is that?

You'll have to ask Intel. As I understand it, the branch prediction and speculative execution portions of the CPU are extremely complicated and cannot be tweaked with a simple fix for this. They'll have to do some major re-design work, which takes years before it reaches a finished consumer product.

[carewolf]

Don't you guys browse the internet? Because it was proven to be exploitable from JavaScript AFAIK,

The JS engines are also isolating, and have been compiled to do that on their own.

[Mangix]

Not for Spectre. No modern x86 CPU has spectre-proof hardware. Here is my 11th gen Tiger Lake machine running Fedora 33. Looks like intel fixed the other stuff, but not Spectre:

Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected

Why is that?

[cl333r]

As far as I know, there have been no reports of any personal computer being exploited by a malicious software taking advantage of these vulnerabilities, ever. Does anyone know of any?
I have all my computers with mitigations=off since I only install from repos or trusted sources.

Same with my PC, and because it's Linux I didn't change my behavior since, apparently you have to wish for it to get a virus.

[tildearrow]

Typo: one of the "CPUs" is written as "CPus"