Maybe you’re right. It’s like we’re all running Macbook Pros, now.
3 Likes
yea, it’s like the patches have even reduced the key travel on my Model M
1 Like
intel CPU bugs are just proof that life is a simulation and the devs are nerfing OP gear
2 Likes
Funny, I said that half joking a little while ago and nobody seemed to care.
lots of things are harmful, but everyone still does them
Something I missed before: I don’t think it is a coincidence that this is high on the list, actually the second point on the FAQ, only second to “… running Intel? Yeah, you’re fucked, mate.”
Multiple teams and researchers independently discovered, studied, and reported MDS-class vulnerabilities and attacks to Intel. Unfortunately, the different timelines (see below), as well as the fine-grained vulnerability classification and embargo strategy enforced by Intel (which coordinated the disclosure process) made proper coordination across teams impossible. The year-long disclosure process (the longest to date) ultimately resulted in independent finders of even closely related MDS-class vulnerabilities to be completely unaware of one another until a few days before the May 14 disclosure date.
We worked with Intel to make sure we’d give proper credit to everyone involved in the disclosure of these vulnerabilities, both in our papers and on this website. This website is our last-minute effort to coordinate the different teams, presenting the two independent papers (and counting?) on RIDL and Fallout.
3 Likes
It really is. But on the bright side, that 9700k without HT makes a lot more sense.
Not that I would buy one. My next CPU will be AMD, and I’ll disable SMT on it.
2 Likes
Think of it this way, now you have something that can both heat your house AND let strangers mine crypto. Everyone wins!
1 Like
Maybe not…
My bad, must be the meltdown they were not susceptible to
1 Like
Yes, Meltdown was an actual bug, as opposed to an unintended consequence of the design principles in all CPUs for the past 20 or so years.
Lol… from el reg
“Intel is not recommending disabling HT,” a company spokesperson told The Register in an email.
"It’s important to understand that disabling SMT/HT does not alone provide protection against MDS, and doing so may impact workload performance or resource utilization that can vary depending on the workload.
i.e., we are so broken, you can’t even disable SMT to fix…
2 Likes
Nah, meltdown was a consequence of executing speculatively BEFORE checking whether or not said code would cross security boundaries. And then relying on thinking they could back out any detectable effects of said code - and failing.
AMD were not impacted by meltdown because they did not make that trade-off. They do not speculatively execute across security boundaries. There’s an IPC hit for not doing that…
THAT was a conscious performance vs. security risk/trade off that intel made, and others did not.
4 Likes
That’s the base way both of the attacks work. The bug with Meltdown is that Intel CPUs are unusually aggressive in an attempt to keep the pipeline full of micro-ops no matter what, which makes timing attacks much faster and more effective. That’s why Meltdown was such a huge deal, because it was much easier to use, and also why it could actually be fixed, albeit with a performance impact.
The core design fault of speculative execution can’t really be fixed; that’s Spectre. Spectre exploits will keep on coming indefinitely until the way we design CPUs changes. Zombieload is just the newest one.
1 Like
That’s intel-marketing–friendly-speak for “overly keen to step over security boundaries for cheap/sketchy performance wins”.
Spectre, sure - intel were more vulnerable there too and speculative execution is an issue. But intel went bone-headed retarded security wise chasing performance. As demonstrated first by meltdown and now by these 3 attacks.
I’m genuinely keen to see Bulldozer re-benchmarked against a modern i7 from the past 2-3 generations of intel post microcode fix AND with hyperthreading disabled (as suggested by OpenBSD that it is too broken on intel to fix) to see just how things stack up today.
Man. You’d be pissed if you bought an i9 or 4c/8t i7 lately. You’ve essentially pissed money up against the wall vs. the non-hyperthreaded lower end, cheaper part.
I’m really expecting to see people launch class-action suits at intel over this.
edit:
never mind cloud/enterprise who have seen performance tank horribly with intel over the past 18 months. no wonder EPYC is getting lots of datacentre wins.
right now for example i have a fairly CPU stressed intel based blade chassis that still has 2 years left on it before replacement (Cisco UCS). We’ve just added 2 new blades… and now find that in order to be properly secure we may need to turn hyperthreading off? LOL…
edit:
Doesn’t impact AMD…
Linus had some choice words for intel and their CPU design team when meltdown was out. I’m sure he’s straining to keep quiet after his empathy training right now 
2 Likes
The million dollar question: how likely is it that we’ll see these exploits in the wild?
There have been precisely zero reported instances of Spectre or Meltdown-based exploits actually being used. Steve Gibson even added options to InSpectre that allow you to disable the protection so you can regain the lost performance.
We will know when the paper is presented on 20th of May.
But they have a JAVASCRIPT proof of concept, so i’d say very likely, eventually.
How do you propose you would KNOW if you’d been compromised via any of these vulnerabilities?
also, why AMD is not impacted:
https://www.amd.com/system/files/documents/security-whitepaper.pdf
For cliffnotes, read the bolded bits.
That would be fun, I am still using gen 1 bulldozer 6 core and I am not a heavy user by any means but still not limited in any noticeable way.
Suddenly Intel releasing a high end part a little while ago with no hyper threading looks like they knew what was going to happen and put a part in place to still offer high performance when their other parts needed it turned off. And as per an article above, googles own Chrome OS products are being shipped with hyper threading turned off as the default.
And not a class action but a user here claimed against intel and won for the price of building a new system on the basis that it was built with specific parts for a specific purpose and the the part were retro actively borked by patches and thus were misrepresented when sold originally. That is actually still happening as Intel won’t re benchmark the products that are on sale to represent the loss in performance and are still being sold at day 1 spec which no longer applies after essential patches.
My thoughts also.
The fact that they still continued to sell hyperthreaded parts at a higher cost than non-HT parts though screams class-action to me.
And yes…
Here in australia we have laws regarding fitness for purpose and for goods to be deemed of merchantable quality. These are considered to trump whatever disclaimer the vendor may have. This is why you get a minimum of 2 (? maybe more, i can’t remember) years warranty on apple computers here for example, as our consumer laws override the default 1 year warranty.
An I7 for example was sold and priced as a premium high performance CPU with virtualisation features. The whole point of VM features is to enforce security boundaries.
I really think that with the meltdown, spectre, and this new round of patches, plus disabling of HT as indicated is required to be properly secure, a high end bulldozer 6-8 core part at decent clock would be competitive, certainly with a 4 core i7.
At least in Australia, intel are facing real risks with their CPUs, if dragged down to half their performance or similar vs. what they were sold as… because of our consumer laws.
3 Likes
https://www.phoronix.com/vr.php?view=27874
If looking at the geometric mean of all the benchmarks carried out, the EPYC 7601 averages out to about a 1% hit with its Spectre mitigations. The dual Xeon Platinum 8280 Cascadelake setup with its mostly hardware-based mitigations was slower by 4% with the relevant mitigations enabled (l1tf: Not affected + mds: Not affected + meltdown: Not affected + spec_store_bypass: Mitigation of SSB disabled via prctl and seccomp + spectre_v1: Mitigation of __user pointer sanitization + spectre_v2: Mitigation of Enhanced IBRS IBPB: conditional RSB filling). Meanwhile the dual Xeon Gold 6138 server that unfortunately doesn’t have the hardware mitigations saw a 11% hit from the benchmarks run with these Spectre/Meltdown/L1TF/MDS mitigations or 15% if disabling Hyper Threading as an additional measure based on the benchmarks carried out today.
2 Likes