Nope, No Intel Chip Recall After Spectre and Meltdown, CEO Says (cnet.com)

Hoping the Meltdown and Spectre security problems might mean Intel would be buying you a shiny new computer after a chip recall? Sorry, that's not on the cards. From a report: Intel famously paid hundreds of millions of dollars to recall its Pentium processors after the 1994 discovery of the "FDIV bug" that revealed rare but real calculation errors. But Intel CEO Brian Krzanich said the new problems are much more easily fixed -- and indeed are already well on their way to being fixed, at least in the case of Intel-powered PCs and servers. "This is very very different from FDIV," Krzanich said, criticizing media coverage of Meltdown and Spectre as overblown. "This is not an issue that is not fixable... we're seeing now the first iterations of patches." On Thursday, Intel said it was aiming to fix 90 percent of all Intel products that have been introduced within the past year by end of next week. CNET asked if the company was looking at older Intel processors? From the report: "We're working with [computer makers] to determine which ones to prioritize based on what they see as systems in the field," an executive at the company said. Intel also is fixing the problem in future chips, starting with products that will arrive later this year. Intel is effectively taking the software fixes being released now and building them directly into hardware, he said.

Comments

It isn't his decision

[110010001000]

Once the lawsuits come rolling in he won't have a choice. This isn't fixable. The best you can do is mitigate the damage. Good thing he sold all his stock before this went public.

A recall is absurd. Software is a thing.

[Anonymous Coward]

It's not possible recall all the processors that ever existed. Society doesn't have the resources even to think about such a thing.

Besides, computers run software, which is almost infinitely malleable; it can be crafted to mitigate the problems of hardware—as it has always done. So much of programming is about working around someone else's boneheaded mistakes.

Now, that being said, this is actually a good reason to support FOSS. You cannot trust other people (especially large, flush corporations) to care enough about your particular situation to fix up the software so as to mitigate such problems. If only more software in the world were open to inspection, then at least people who really care could go about fixing things themselves, and the rest of you consumer nitwits could at least benefit from their hard work, too.

We'll get there one day.

Re:Lawsuits on what grounds?

[networkBoy]

I'm guessing you don't work on this stuff do you...

I never worked on the CPUs (I was chipsets), but I certainly have plenty of experience with unintended effects.

* That it trains on other data is a non issue.
* That it allows privileged access as part of a prediction is a mild (at best) issue.
* That it doesn't have a prediction fail recovery mechanism (e.g. zero the cache for the failed prediction) is a minor issue.

HOWEVER
When these component issues combine together it is a *huge* flaw.

How can this happen?
* designers are idiots?
-no, if they were idiots they certainly wouldn't have a working part at all. This stuff is _complex_

* different smart designers worked on different parts, but in isolation?
-ding! winner. It is highly likely that there was more than one team involved and as a result each validated their block works, and they validated that the system works. No one person saw the *whole* picture and as a result this vulnerability exists.

Now, once a designed block is done, the industry standard is to leave it the fsck alone! So this block of VHDL likely was re-used and tweaked for process changes, but never actually fully re-factored, so no one ever saw the big picture at all.

That is how bugs like this come to be.

If you want to beat people up about it, it's not the engineers that should be beaten, it is management that keeps the engineers under such schedule pressure that there is *never* a window to review and refactor something unless it's flatly broken. Beat up senior management for how they're handling this whole thing...

But leave the guys in the trenches out of it. I guarantee you they were doing their best.