Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

Page 70 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

GreenReaper

Junior Member
Aug 15, 2018
8
6
81
After consideration I decide not to open new thread, I have an old DDR2 machine need to renew for emergency usage, the choice is between AMD PhenomII & Intel Core2.
That's not really a specific enough choice. There is great variation in those large families of CPUs. A quad core is likely to be faster than a dual core nowadays, but other than that they can be closely matched.

But an AMD chip is likely to be far less impacted than the Intel equivalent of its time because a significant part of the performance deficit is due to Meltdown, which AMD avoided.

Of course, you could just disable protections via the registry, and hope that you don't run into issues, especially if you are careful about where you go online and what software you run.
 
  • Like
Reactions: cortexa99

GreenReaper

Junior Member
Aug 15, 2018
8
6
81
Some of the newer Spectre-style issues do, yes. In fact a few of those fixes are not enabled by default on Windows because of the cost.

Meltdown does not involve symmetric multi-threading, though; rather, it gets expensive for those older Intel CPUs because they won't have INVPCID (and maybe not even PCID), which helps avoid the impact of having a separate page table for the kernel.

Of course, if you do not have a workload that stresses interrupts, it may not be a problem. But my experience has been that my old Core Duo laptop got a lot slower with a version of Windows with the fixes.
 
  • Like
Reactions: cortexa99

pandemonium

Golden Member
Mar 17, 2011
1,777
76
91
Unless you're using this old machine for professional reasons, I honestly wouldn't worry about the bugs. Correct me if I'm wrong, please, but IIRC we still haven't had an exploitable scenario surrounding any of these exploits.
 

jpiniero

Lifer
Oct 1, 2010
14,510
5,159
136
Unless you're using this old machine for professional reasons, I honestly wouldn't worry about the bugs. Correct me if I'm wrong, please, but IIRC we still haven't had an exploitable scenario surrounding any of these exploits.

Yeah, Windows 10 is a bigger security hole than Spectre and Meltdown will ever be.
 
  • Haha
Reactions: cortexa99

DrMrLordX

Lifer
Apr 27, 2000
21,583
10,785
136
Does IceLake even need those mitigations, though? Shouldn't that be fixed in hardware by now?
 

moinmoin

Diamond Member
Jun 1, 2017
4,934
7,620
136
Spectre nope. Going to be awhile before v1 gets fixed.
Spectre v1 imo is a special case in so far that it doesn't include any privilege escalation, just crossing same level process boundaries. That's something CPU tech just didn't worry about at all since its existence. That's also why it's so hard to "fix" since in that specific case it was really designed that way.
 

moinmoin

Diamond Member
Jun 1, 2017
4,934
7,620
136
The same researchers warned Intel about the vulnerability in April — as it did with the other flaws they discovered that were patched a month later. Intel took until this month to investigate, the researchers said.

1573600395443.jpeg
 

moinmoin

Diamond Member
Jun 1, 2017
4,934
7,620
136
Ugh, what do we know, of course it gets far, far worse...

Intel actively uses NDAs to silence the security teams and lie to its customers. Now those NDAs ran out on November 12th so we get to check what Intel prevented from being disclosed. Above "new" Zombiload ain't new, "new" TSX Asynchronous Abort ain't new. Intel told us we could be secured against with software updates? No, the wording of choice is rather "mitigate any potential security threats", and stuff like Jump Conditional Code is not even being handled as security issue, but is bound to reduce gaming performance some more.

But back to Intel's (ab)use of NDAs, part of the security team that found Zombiload is from Austrian Technical University of Graz, and German language futurezone.at did an interview with its member Daniel Gruss (going to paraphrase his major answers):
  • When Intel falsely claimed Cascade Lake were not affected by Zombiload the team couldn't object due to the NDA.
  • The NDA was extended to November on very short notice. Now it looks it was only done to not endanger sales of the then upcoming products (i.e. mislead the customers).
  • Thinks no software can fix the vulnerabilities, suggests turning off TSX, and in general Hyper Threading.
Timeline of the MDS Attack disclosure (bolded text is from source):

On Sep 29, 2018, we submitted several proof-of-concept exploits (PoCs) for a number of RIDL variants to Intel. Despite our many attempts, we received no technical feedback/questions on our submission except that Intel was working on the mitigations.

In fact, due to a lack of transparency on Intel's part, we only got a complete picture on Intel's MDS disclosure plan on May 10, 2019, just 4 days before public disclosure. We were able to find the microcode updates published by Intel online and tested them on May 11. We quickly found that Intel's fixes did not fully mitigate the vulnerabilities we had reported in Sep 2018 and immediately informed Intel.

On May 13, 2019, just one day from the RIDL/MDS public disclosure date, Intel requested TAA and any other RIDL issues that were not mentioned in the MDS whitepaper to be placed under a new last-minute embargo until Nov 12, 2019. At the request of Intel, and to protect users, we complied to the new embargo, withheld several details from the RIDL paper (leaving only some traces of our results in Table I), and did not release our now public RIDL test suite.

On July 3, 2019, we finally learned that, to our surprise, the Intel PSIRT team had missed the PoCs from our Sep 29 submission, despite having awarded a bounty for it, explaining why Intel had failed to address - or even publicly acknowledge - many RIDL-class vulnerabilities on May 14, 2019.

On Oct 15, 2019, we learned that Intel had not found this issue internally and the only other independent finder was the Zombieload team, which disclosed TAA to Intel in April, 2019.

On Oct 25, 2019, we tested Intel's latest microcode update, and still saw leaks with the VERW mitigation enabled, using the RIDL PoCs we shared with Intel in May 2019. We notified Intel and shared a polished PoC to make the issue clear. Intel requested a new embargo and yet suggested adding the following to our RIDL addendum: "A new microcode update release by Intel in November is required to adequately address the issue".

On Nov 12, 2019, TAA and the other scheduled RIDL issues are disclosed. Unfortunately, we believe that, given the piecemeal (variant-by-variant) mitigation approach pursued by Intel, RIDL-class vulnerabilities won't disappear any time soon.


Everybody involved in this continuous mess at Intel needs to have a long hard look into the mirror (and ideally change profession thereafter).
 

Gideon

Golden Member
Nov 27, 2007
1,608
3,573
136
On May 13, 2019, just one day from the RIDL/MDS public disclosure date, Intel requested TAA and any other RIDL issues that were not mentioned in the MDS whitepaper to be placed under a new last-minute embargo until Nov 12, 2019. At the request of Intel, and to protect users, we complied to the new embargo, withheld several details from the RIDL paper (leaving only some traces of our results in Table I), and did not release our now public RIDL test suite.

WTH? This is absolutely outrageous behavior!
 
  • Like
Reactions: KompuKare

Kocicak

Senior member
Jan 17, 2019
982
973
136
What would be the impact on performance, if they turned the speculative execution completelly off?
 

Kenmitch

Diamond Member
Oct 10, 1999
8,505
2,248
136
Gaming the system in the guise of protecting the end user? Intel has to be playing a 'draw it out strategy' as they try to remedy these failures.

You do realize they're the kings of gaming. Just another form of it.

Things would most likely be a whole lot different if AMD's offerings weren't so dang competitive and in some cases superior. Intel doesn't have much wiggle room in performance these days.
 

moinmoin

Diamond Member
Jun 1, 2017
4,934
7,620
136
Gaming the system in the guise of protecting the end user? Intel has to be playing a 'draw it out strategy' as they try to remedy these failures.
The way they apparently handle well known security teams (those where already involved in documenting Sprectre and Meltdown fgs! If I were Intel I'd give them top priority treatment) and schedule fixes they don't appear to take security seriously at all internally. More like their marketing department appears to make the scheduling and budgeting decisions for anything security related. So I'd say they are in serious danger of gaming themselves out of the market. I'm honestly dumbfolded that this isn't blowing up in their face.
 
  • Like
Reactions: KompuKare

Mopetar

Diamond Member
Jan 31, 2011
7,797
5,899
136
Gaming the system in the guise of protecting the end user? Intel has to be playing a 'draw it out strategy' as they try to remedy these failures.

It really isn't protecting the end user any more than your doctor covering up part of the x-ray that contains a massive tumor is protecting his patient.

I realize that most of this stuff isn't going to affect standard users at all, because frankly it's much easier to just get idiots to download and install a trojan by telling them it will let them chat with hot singles in their area than to create something using any of these exploits, but if I were a government agency or any company with valuable secrets I'd be wary as hell about buying anything from Intel with practices like this in place that leave me exposed. You have to know that countries like the U.S. and Russia have been researching these problems as well and are a lot less interested in disclosing the vulnerabilities that they discover.