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.

12 of 372 comments (clear)

  1. It isn't his decision by 110010001000 · · Score: 5, Insightful

    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.

    1. Re:It isn't his decision by 110010001000 · · Score: 4, Insightful

      WRONG. The Meltdown attack ONLY AFFECTS INTEL PROCESSORS. We need to keep this lie from spreading.

  2. A recall is absurd. Software is a thing. by Anonymous Coward · · Score: 5, Insightful

    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.

  3. Lawsuits on what grounds? by Anonymous Coward · · Score: 1, Insightful

    Caveat Emptor.

    Intel offered a product, and you chose to buy it. The whole thing was voluntary. There was no fraud, either; Intel never said its chips were free defects; indeed, anyone who has had even a passing interest in the world of computing knows that a huge amount of software (especially kernel stuff) is devoted hiding and working around hardware-level "quirks" (read: bugs).

    If anybody sues Intel, they'll be suing Intel only for providing an optional feature that makes computations faster. That's it. You don't want the security risk? Well, turn off that optional performance optimization.

    1. Re:Lawsuits on what grounds? by 110010001000 · · Score: 4, Insightful

      No they aren't if they are trading on information that the public doesn't know about.

    2. Re:Lawsuits on what grounds? by 110010001000 · · Score: 2, Insightful

      Give me a break. One of the key features of the processor is not allowing access to kernel memory from processes that shouldn't have access. Really, just stop. Too stupid.

    3. Re:Lawsuits on what grounds? by networkBoy · · Score: 5, Insightful

      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.

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
    4. Re: Lawsuits on what grounds? by sexconker · · Score: 3, Insightful

      It's Hillary "Correct the Record" levels of horseshit.

    5. Re:Lawsuits on what grounds? by Anne+Thwacks · · Score: 4, Insightful
      I'm guessing you don't work on this stuff do you...

      Well your guess is partly right. I am retired now. However, I did work designing CPUs, and I was specifically employed to debug pipelining snafus, so yes, I do know something about the subject. (I did not work for Intel).

      The "training on other threads' data" is not in itself a very serious security issue, but it is certainly an information leak between threads, and would probably be acceptable if the data leaked was the value of a random byte, as it might have been 20 years ago.

      The problem here is serious because this situation allows deliberate (mis-)training of performance in the other guy's thread! - That is not what is being complained about in Meltdown or Spectre and is not necessarily a security risk, but it is not good news if some-one else's C library calls can screw the performance of my thread. Meltdown specifically describes shared C libraries as a source of predictable data to screw with.

      In the present situation, where the CPU speculatively executes hundreds of instructions at a time, it gives a massive surface of attack which simply should not be there.

      I give you "designers working in isolation" is going to lead to trouble, as is too much focus on schedule, but re-using vhdl blocks you don't understand counts as idiot behaviour in my books - although re-using blocks you know are "a bit iffy" is possibly worse: people must have known that kernel memory could be accessed speculatively. I would not have knowingly bought a processor that allowed that for cloud type uses. There is a risk of billion dollar law suits involved.

      As I have said elsewhere, I would expect reading the pipeline contents for speculative execution that is abandoned to be restricted to (a) kernel mode, AND (b) only when in a debug mode. There simply should not be a way for user mode threads to see this data at all in normal operation - it is only needed to debug the speculative execution engine. I would not expect the data to be able to leave the CPU in normal operation. In fact, I would expect to need jtag to read it. The car analogy is driving your van away with the back doors open. Sure, the parcels might not fall out! (Just because its still your thread does not mean you want an information leak: this is the browser risk).

      --
      Sent from my ASR33 using ASCII
  4. Re:Same syndrome as VW by Megol · · Score: 3, Insightful

    Bullshit. The suggestion is frankly completely bonkers - there are no similarities at all!

    What you are suggesting is that Intel willingly incorporated a security violating bug in order to gain some performance... How the hell would that work out?

    No don't respond as it's obvious you don't know enough to answer.

  5. This doesn't surprise by rsilvergun · · Score: 4, Insightful

    A lot of users won't be impacted. 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. It's looks like enough to knock him down to high end i5 territory. That's about $75-$100 worth of performance gone in a puff of smoke....

    --
    Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
  6. Re:Same syndrome as VW by Stormy+Dragon · · Score: 3, Insightful

    What you are suggesting is that Intel willingly incorporated a security violating bug

    It found out about the bug in June and continued to sell defective processors for the last seven months.

    So yes, Intel willingly incorporated a security violating bug, for at least the last seven months.