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

[ddriver]

What's up with 5950X? It seems to be affected more than the older AMD chips. The AMD chips overall suffer a bit more than I expected.

Zen 3 is a lot more "snappy" compared to previous iterations. So it stands to lose more of that snappiness from mitigations getting in the way of optimal operation.

Much like a sports can will lose more of its top speed driving through a corn field than a mainstream car.

Although them encryption results look more like a bug than mitigation penalty.

[Michael]

Although them encryption results look more like a bug than mitigation penalty.

See the aforelinked and past articles around AES-NI XTS in the presence of Retpolines.

[tildearrow]

I wonder why is the 5950X being hit hard here......

More cores or more vulnerabilities? Or slower mitigations?

[Mangix]

I thought new hardware had hardware fixes for this. Why are mitigations still enabled?

[Jabberwocky]

If you trust your distro and software, mitigations=off FTW !

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

[Jabberwocky]

I wonder why is the 5950X being hit hard here......

More cores or more vulnerabilities? Or slower mitigations?

I have the same question, something looks very wrong with the results. I don't know if this is kernel, kernel-scheduling, compiler or even application related.

There are many changes between Zen3 and Zen2 ... much more than Zen2 and Zen1. The 4 to 8 CCX alone is massive in how the chip's internal latency behaves. I have not been following patches at all, so I'm sorry if I've missed something directly related to this change in hardware. In any case rather big change in scheduling would have been required. There are many other factors that would require optimization for many individual instructions, yet I don't think that this is a problem maybe just a missed optimization. Windows applications probably don't have these optimizations and they appear to get much better results from zen3 CPUs. As always info from wikipedia and wikichip is very useful for reviewing hardware changes, however this time I found Anandtech's research was outstanding.

Typically when designing a CPU core, the easiest thing to do is to take the previous design and upgrade certain parts of it – or what engineers call tackling ‘the low hanging fruit’ which enables the most speed-up for the least effort. Because CPU core designs are built to a deadline, there are always ideas that never make it into the final design, but those become the easiest targets for the next generation. This is what we saw with Zen 1/Zen+ moving on to Zen 2. So naturally, the easiest thing for AMD to do would be the same again, but with Zen 3.

However, AMD did not do this. In our interviews with AMD’s senior staff, we have known that AMD has two independent CPU core design teams that aim to leapfrog each other as they build newer, high performance cores. Zen 1 and Zen 2 were products from the first core design team, and now Zen 3 is the product from the second design team. Naturally we then expect Zen 4 to be the next generation of Zen 3, with ‘the low hanging fruit’ taken care of

https://www.anandtech.com/print/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested

They found out some things that AMD did not publish (not part of the quote below). It's a good long technical read.

[torsionbar28]

I thought new hardware had hardware fixes for this. Why are mitigations still enabled?

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

[tildearrow]

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

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

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