Slashdot Mirror


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.

6 of 372 comments (clear)

  1. Sorry, but no, sorry. It's not "fixed" by Opportunist · · Score: 5, Informative

    Well, maybe in the veterinary sense, but I didn't plan to buy a castrated CPU.

    First, the problem is in the processor logic itself. We're talking about a design flaw that could only "really" be patched by re-etching the silicon. I highly doubt that he has found a way to rework the die. This isn't some BIOS feature we have to patch. Intel's promise now is that they found a way to manage the problem in microcode. And whether the microcode patch will do any good is still to be seen. Personally, my stance is "seeing is believing".

    Mostly because there is a second aspect: ALL, and I do mean ALL, possible approaches to fixing this can only be done with a drop in performance. There is no way this can be addressed without taking a performance hit. Especially high I/O applications like database processing is severely affected by the current patches, postgresql cited performance drops of up to 30%.

    Simply having the gall to state that this is no reason for a recall takes quite the chutzpah. I kinda wonder whether various high performance data centers will simply swallow this.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  2. Re:Lawsuits on what grounds? by Anne+Thwacks · · Score: 5, Informative
    OTOH if the "lock" won't remain closed if you "look at it from the wrong angle", then its not a lock, its a scam.

    This design error contains at least three features worthy of "www.wtf.com":

    • The branch prediction trains on other people's threads: that is like your satnav giving you directions based on other cars movements.
    • The speculative execution can access data it is not supposed to: that is like you can imagine your are in a different person's house, and nick their things. Even in the 1970's the data returned by other 16 bit machines in this situation would have been "0xf001" and by 24 bit ones "FOOL" as 6-bit baudot code. Its not like this is not a well documented situation.
    • You can read the pipeline cache for speculative stuff that was abandoned when not in kernel AND debug mode that on its own is a completely unacceptable design defect. Worse, since it was known to contain other threads' data (at least by Intel).

    That is the three no-nos we know about. There must be at least one more we don't know being held back because it is even worse.

    Whoever designed this stuff MUST have known it would behave like that, same way the Volkswagen engineers knew what was going on. Someone signed the designs into production. Presumably the first time round it was "let's chance it" and subsequently "well, we got away with it last time".

    I am guessing quite a few people knew about some of it - like people debugging the compilers for example.

    If you want to know why NDAs should not be permitted this is it! Use an Open Source architecture if you want accountability.

    --
    Sent from my ASR33 using ASCII
  3. Re:It isn't his decision by 110010001000 · · Score: 4, Informative

    WRONG. Repeating the lie doesn't make it true. MELTDOWN is INTEL ONLY. You are talking about a different issue. Please stop.

  4. Re:This doesn't surprise by thegarbz · · Score: 4, Informative

    My brothers pissed because this is going to tank performance in the IO heavy strategy games he plays and he bought his i7 specifically to play them.

    Where'd you get this from? So far the only benchmarks I've seen show sweet fa difference for any kind of gaming before and after the patches.

  5. Re:It isn't his decision by 110010001000 · · Score: 5, Informative

    FROM THE PEOPLE WHO ACTUALLY FOUND THE FLAW:

    https://spectreattack.com/

    Which systems are affected by Meltdown?
    Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, 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). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors.

    Really, are you that ill-informed?

  6. Re:It isn't his decision by Anonymous Coward · · Score: 5, Informative

    FROM THE PEOPLE WHO ACTUALLY FOUND THE FLAW:

    The GP's "Citation please" was referring to the fact that "MELTDOWN is INTEL ONLY." AFAICT. Which it is. From Section 6.4 of the Meltdown paper:

    We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD.

    In summary:
    * Meltdown: Intel-only
    * Specture: everyone