Intel Makes Public Two More Data Leakage Disclosures

[HyperDrive]

Some vulnerabilities go all the way back to Core2.

Quoting Intel itself, "every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013)".

[skeevy420]

Some vulnerabilities go all the way back to Core2. I don't think Westmere has as many vulnerabilities as, (for example) Haswell, but if the CPUs are patched and still delivering sufficient performance, I'm not sure how much any of that matters.

At this point, I've lost track of how many vulnerabilities there are, which CPUs are affected, and how much of a performance deficit their mitigations have. I'd like to see a full comprehensive chart showing each vulnerability and each CPU generation that's affected. I've seen charts, but they were kinda vague.

That's what I was assuming.

It seems that we're all just as ??? about exact details and how noticeable or not certain fixes are, even with comprehensive benchmarks. No matter how well Michael does his benchmarks, between new compiler fixes and features, old projects growing and evolving due to the former, new projects being added (to distributions, etc), fixes in firmware, and more, it has to be a motherfucker to comprehensibly track, test, and plot what's doing what to what effect.

My old system got an update last November and, last I checked, my CPUs were squeaking by on support from Intel so there's that.

I say Michael up there because he does some of the best and comprehensive benchmarks around and if he hasn't provided that kind of information, no one outside of Intel and, I dunno, Dell, since that's what I have, with access to lots unpatched hardware could provide it. Like on that article on Westmeres and Debian over the past few years, the only real conclusion to be made was "mitigations did have some effect" and "thank goodness, they're really nowhere near as bad as I expected" because so much other stuff has changed between then and now that it's hard to blame just the mitigations unless every mitigation is tested one and at time...and by now that's like a stupid high amount and would take a long time due to needing custom GCCs and LLVMs and whatnot...fsck me, it's a headache just thinking about.

[uid313]

That has nothing to do with x86 every modern architecture has a branch predictor or speculative execution. Thats the reason some ARM processors were also affected.

But Intel have had a long list of vulnerabilities. Spectre, Meltdown, TLBleed, Foreshadow, etc.

[CochainComplex]

I think we will consider the P4 as a competitive CPU again soon.

[MadCatX]

Oh... it must be Wednesday again.

[ThoreauHD]

Intel needs to start scheduling a happy hour during their weekly vulnerability releases. At least make it fun.

[timofonic]

Bugtel strikes again...

[pepoluan]

But Intel have had a long list of vulnerabilities. Spectre, Meltdown, TLBleed, Foreshadow, etc.

Yes, but many of those vulnerabilities do not affect AMD's x86 processors. That's why the "Swiss cheese" analogy is not accurately applicable to x86.

[torsionbar28]

You mean 10 years of telling their QA engineers to get out of the way because zomg performance!111!!!

I wonder how many of these recent flaws intel knew about way back in the design stage, and made the conscious decision to choose performance over security? I'd wager most or maybe all. Honest mistakes do happen from time to time, the original P5 FDIV bug, for example. But when fixing the "problem" creates a significant performance hit, Intel's faulty design seems intentional.

I should probably be more grateful for intel's bumbling. As an AMD shareholder since early 2016, I'm laughing all the way to the bank. AMD FTW!

[starshipeleven]

I wonder how many of these recent flaws intel knew about way back in the design stage, and made the conscious decision to choose performance over security? I'd wager most or maybe all. Honest mistakes do happen from time to time, the original P5 FDIV bug, for example. But when fixing the "problem" creates a significant performance hit, Intel's faulty design seems intentional.

I doubt it, any QA in both software and hardware development (and in actual manufacturing) is going to find so. much. crap. regardless of how good your designers or production process are.

In cases like this, if your QA does not find a lot of stuff it's probably bad at its job. We aren't talking of basic easy dumb things with large tolerances like say sledgehammers, this is extremely complex electronics, making small mistakes is going to affect the end product in significant ways.