Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Intel Bug

Intel Urges OEMs and End Users To Stop Deploying Spectre Patch As It May 'Introduce Higher Than Expected Reboots' ( 155

Intel executive vice president Neil Shenoy said on Monday that the chip-maker has identified the source of some of the recent problems, so it is now recommended that users skip the available patches. From the blog post: We recommend that OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions, as they may introduce higher than expected reboots and other unpredictable system behavior.
This discussion has been archived. No new comments can be posted.

Intel Urges OEMs and End Users To Stop Deploying Spectre Patch As It May 'Introduce Higher Than Expected Reboots'

Comments Filter:
  • Oh? (Score:5, Insightful)

    by jawtheshark ( 198669 ) * <slashdot@jawthesh a r> on Monday January 22, 2018 @03:24PM (#55979985) Homepage Journal
    You mean like, more than zero? Apart from a planned a kernel upgrade I never reboot. My systems also don’t reboot spontaneously.
    • by Anonymous Coward

      Apart from a planned a kernel upgrade I never reboot.

      I thought my daily reboots would go away when I upgraded to WinME. No such luck.

      • by arth1 ( 260657 )

        I thought my daily reboots would go away when I upgraded to WinME. No such luck.

        The "reboot at least every 43 days" bug that plagued Windows 98 went away when upgrading to Windows Me, though.

    • My systems also don’t reboot spontaneously.

      You're going to love these patches then. Life is full of new experiences. :(

    • by Anonymous Coward

      You clearly only have a few hundred servers. If you had thousands you would start to notice several unexplained reboots year. Some you would blame on hardware, others on software, some would be unexplained. You might post your kernel dump expecting some sort of mass panic that you had found a crash but most likely it would just go with the thousands of other crash reports and you would realise that kernels are full of unfixed undiagnosed bugs.

    • by nmb3000 ( 741169 )

      It is a pretty remarkable euphemism. Imagine prescription drugs had disclaimers written like this:

      "Notice: This product may introduce higher than expected deaths."

      Sign me up!

      • by aliquis ( 678370 )

        My dad died in pneumonia after having being given Risperdal while he had Alzheimers, something the FDA recommends against doing considering exactly that. I don't know if the manufacturer say so themselves but supposedly it is the case.

      • Haven't you listened to the lawyer-speak at the end of pretty much every drug commercial? For instance, Breo Ellipta, an inhaler used to treat asthma has this warning "People with asthma who take long-acting beta2-adrenergic agonist (LABA) medicines, such as vilanterol (one of the medicines in BREO), have an increased risk of death from asthma problems." (Emphasis added)
    • When you're running thousands of systems, spontaneous reboots happen. Could be due to some power fluctuation caused by a flaky PSU for example. Intel's now saying that the expected number of spontaneous reboots has risen with the new microcode.

      When running a few systems you shouldn't notice spontaneous reboots.

  • by Anonymous Coward

    Iâ(TM)m glad they are telling us to leave our systems insecure, that is helpful advice

  • Couldn't be bothered to do it right the first time.

  • by dos1 ( 2950945 ) on Monday January 22, 2018 @03:25PM (#55979997)

    "Higher than expected reboots"? What kind of newspeak is it?

  • by Anonymous Coward

    When can we deploy that, Intel?

  • Was Intel expecting? Me, I was expecting one to install the patch. I guess anything more is, technically, higher than expected. Also, this kind of mealy mouthed garbage is why Linus is so made at you right now Intel...
    • by Anonymous Coward
      I believe you answered your own question.
    • by arth1 ( 260657 )

      Was Intel expecting? Me, I was expecting one to install the patch.

      You don't need a reboot for the Intel patches. Those are microcode updates, which can be applied on a running system.

      (Reverting to an earlier version of microcode requires a reboot, though.)

  • by Hadlock ( 143607 ) on Monday January 22, 2018 @03:28PM (#55980033) Homepage Journal

    Did they just roll out a patch in the last 30 days, or what's going on over there? This is the kind of instability one would expect from a hastily produced patch developed over a month by a small team. According to reports, Intel has known about the vuln for 7+ months. Were they not working on a patch this whole time? I would assume they were on iteration 5 or 6 of the patch by the time they broke the embargo a week early.

  • by Anonymous Coward

    Some famous person should finally bomb intel over their "higher than usual" BS. It's an insult to every single person who's reading this idiotic Slashdot news post. Non-broken "systems" don't have "unexpected reboots" ever. FFS.

  • by forkfail ( 228161 ) on Monday January 22, 2018 @03:39PM (#55980141)

    ... to Intel's announcement.

    Especially given what he had to say about the patches in the first place: []

    • by HiThere ( 15173 )

      You may wait awhile. For Linus to comment on patches is reasonable. He rarely comments in an interesting way on things that he has criticized being withdrawn.

    • I missed that one somehow, that was fantastic. Almost to the level of his famous nvidia rant.

  • Maybe it's time for a slightly more measured approach?

    • by RhettLivingston ( 544140 ) on Monday January 22, 2018 @04:10PM (#55980405) Journal

      The fact that they took half a year to deliver this cluster**** could be an indicator that no true "fix" is possible or that the performance losses of a true fix would have a far worse overall impact than just accepting random reboots.

      I understand that they'd likely need a multi-government bailout and years of production time to replace all of the broken processors, but facing reality and moving forward with a real fix feels like the healthiest thing for the system as a whole. How much time and money is being wasted worldwide by IT folks and software engineers on this fiasco?

      • by el borak ( 263323 ) on Monday January 22, 2018 @04:40PM (#55980631)

        The fact that they took half a year to deliver this cluster**** could be an indicator that no true "fix" is possible or that the performance losses of a true fix would have a far worse overall impact than just accepting random reboots.

        You're assuming they spent half a year working on a fix. I think it's far more likely that:

        2 months were wasted by engineers trying to convince management that the problem really was potentially very serious

        2 months waiting for management to try to figure out who to blame and how to make sure it wouldn't reflect negatively on them or impact their departmental budget or personal performance bonuses

        1.5 months for PR to come up with the best possible language to make sure they could paint the entire industry as being equally affected, while simultaneously the lawyers tried to find the largest possible scraps of TP to cover their corporate *sses

        .5 months working on a fix

        • by Anonymous Coward

          You skipped 2 months having a few engineers trying to convince their peers that this is real. Don't discount the effects of self-indoctrination when you've been telling yourself and your peers that this clever, patented hack that beats the competitors is perfectly safe and any imaginable attack is "purely academic."

      • Do we really know they were actively working on a fix for half a year? I hadn't seen anything but speculation to that effect, but may have missed it.

        • Do we really know they were actively working on a fix for half a year?

          We know that they should have been.actively working on a fix for half a year.

      • This - it's not truly fixable.

  • by Andrew Lindh ( 137790 ) on Monday January 22, 2018 @03:49PM (#55980243)

    "We recommend everyone stop deployment of Intel CPUs". Higher than expected reboots? More than 1 to install the update? The root cause is design flaws and inadequate testing of major low level patches. Google new about these issues months ago and Intel did (or should have) too. They rushed the release so the stock price does not tank not because it was ready. They normally take many months or years to test these design changes or updates and now it will be a long time before they have new CPUs that don't need fixes (or at least these fixes). May be they should have worked around the clock months ago when they did not need to be rushed.

  • by oldgraybeard ( 2939809 ) on Monday January 22, 2018 @03:53PM (#55980277)
    The only way to truly fix things is to replace the CPU. And that would really hurt/destroy Intel's bottom line.

    Which leaves them flailing about wildly for some other appearance of a solution/solution to, at the very least cover their butts, mean while costing them a little as possible.

    Just my 2 cents ;)
    • by nwf ( 25607 ) on Monday January 22, 2018 @05:02PM (#55980817)

      Replacing the CPUs is likely something they can't do anytime soon, since I'd guess none of the next 2 years worth of CPUs will have a fix for this. Spectre can't be fixed in the general case, I believe.

      Replacing is really the only viable option for performance-critical applications (which most users don't have), but Intel is never going to give them out. I can see after some massive lawsuits that they offer a 10% discount on a new CPU (for which you need a new motherboard). It's likely going to help their bottom line.

      • by HiThere ( 15173 )

        I'm sure that Spectre *can* be fixed, though we may not currently know the best way. But Meltdown is the current real problem (as opposed to the problem a few months from now, when a new exploit is revealed).

        And it's my guess that Intel can't fix Meltdown in any of it's current chips without disabling speculative execution entirely. Which, of course, would solve Spectre, but would also make them a LOT slower than AMD.

        And by "Intel's current chips" I'm including all those whose masks have already been desi

    • by rsilvergun ( 571051 ) on Monday January 22, 2018 @05:43PM (#55981085)
      and plan to look into the class action suits. Had I known I would have held off or bought a Ryzen. I'm not expecting Intel to buy me new CPUs but as a gamer the 5-10% hit I'm seeing will eventually caught up to me and force an upgrade sooner than intended.
      • but as a gamer the 5-10% hit I'm seeing

        That's quite interesting given that this isn't born out in any of the very many benchmarks that have been done on this. There were plenty to show that gamers experience precisely zero difference. There were more that show in most cases if your CPU is only a year old and has PCID you won't see anything near a 10% hit.

        Now if you said you were a server administrator and your corporate webserver or backend database started chugging, that would be quite believable.

        But by all means class action away. I'm sure the

        • There's a hit there on the top end. Also in synthetics. I'm not currently seeing the frame rate dips because my GTX 760 bottlenecks that. In 5 years that won't be true (just like it wasn't true when I put that 760 on my old A10-5800). I don't upgrade my CPU & GPU in tandem. I tend to buy more CPU than I need and wait for the price of graphics to come down.
          • Interesting, thanks for pointing that out. The very first review I found showed a 9.8% penalty on Witcher 3 while zero penalty on most of the other games under test. Interestingly Witcher 3 also gave the highest frame rate, does that mean the rest of the games are GPU bound and Witcher 3 presents an unnaturally high CPU load?

            If so what is it about Witcher 3 that taxes the CPU more than other games? Isn't it just an 3rd person RPG?

            • maybe a 1070. Both of those are way outside my price range. But so was the equivalent to the 760 I'm rocking now. Heck, the i5 I just bought only just now came down to what I was willing to pay (got it for $150 on sale at Fry's Electronics). But it's still overkill for all the games I play and will be for the next 5 years... if the performance doesn't tank due to patches. I mostly play console ports that are GPU bound.
  • by hey! ( 33014 ) on Monday January 22, 2018 @04:07PM (#55980385) Homepage Journal

    In other words their patch crashes your machine.

    This reminds me of the various colorful circumlocutions people around the world use for death. In France someone who dies "eats daisies by the roots". In Germany he "gives up his spoon". In China he "goes to sell salted duck eggs."

    I suppose in Intel-speak death would be "non-transitory pulmonary quiescence."

  • Golfclap?

  • by Arzaboa ( 2804779 ) on Monday January 22, 2018 @04:14PM (#55980433)

    Can't steal data from a CPU while its power cycling!

    Round and a round and a round we go

  • So after having months and months to create a patch to their borked design, they fail.
    Now in a few measly weeks (days) they have a real patch that's going to do the job.
    For everyone (including me) that started performance testing patches before you deploy them.... back to Step 1.

  • Whereas eating a healthy diet and exercising regularly causes fewer than expected deaths.
  • by Gravis Zero ( 934156 ) on Monday January 22, 2018 @04:45PM (#55980685)

    Not only has the microcode patch caused unexpected reboots from Intel's CPUs but it's also causing spontaneous AMD purchases! ;)

  • "Unpredictable system behavior".
  • Spectre cannot be practically used for any exploit - it's Intel PR's red herring, it's bullshit.

    Just read up, educate yourselves (though half the people on /. are the proverbial choir I'm preaching to, I guess).

    • by jbmartin6 ( 1232050 ) on Monday January 22, 2018 @05:57PM (#55981181)
      Multiple [] exploits [] are available, aren't they?
      • by sjames ( 1099 )

        The first link is a POC that a process can read it's own memory space and privilege level without explicitly accessing it. I wouldn't call it nothing since it could allow javascript to access scripts running in other tabs, but the utility is very limited compared to meltdown and browsers are already in the works that prevent it.

        Meltdown really is orders of magnitude worse.

      • Did you even read that? First of all, the scenario in that example stores sensitive data in userspace - nobody does that. Second of all, and more critically, the code knew where to look for the data, which extremely unrealistic.

  • by Anonymous Coward

    My next system will be AMD.

    Lack of ECC support in desktop SKUs, cheeping out on PCIe lanes and a string of zero integrity marketing doublespeak including campaign to conflate meltdown /w spectre and now "higher than expected reboot" being the main reasons.

    General existence of timing side channels against branch predictors has been public knowledge for at least 15 years. Now when a ridiculous UNRELATED problem is discovered in Intel silicon red alert spectre spectre spectre... they are breaking shit and cau

  • Intel Inside!
    (Sorry about your luck dude)

  • by Anonymous Coward

    Oh rite. Already did.

    When is that fucker going to be charged?

  • So after all the trouble we went through (mostly me) at my company to push the patches and the constant demand from our parent company to provide progress updates amidst a global panic, now I'm what, supposed to undo it all and stay vulnerable?

    Go to hell Intel.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.