Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Google Intel BSD Hardware

OpenBSD's De Raadt Pans 'Incredibly Bad' Disclsoure of Intel CPU Bug (itwire.com) 366

troublemaker_23 quotes ITWire: Disclosure of the Meltdown and Spectre vulnerabilities, which affect mainly Intel CPUs, was handled "in an incredibly bad way" by both Intel and Google, the leader of the OpenBSD project Theo de Raadt claims. "Only Tier-1 companies received advance information, and that is not responsible disclosure -- it is selective disclosure," De Raadt told iTWire in response to queries. "Everyone below Tier-1 has just gotten screwed."
In the interview de Raadt also faults intel for moving too fast in an attempt to beat their competition. "There are papers about the risky side-effects of speculative loads -- people knew... Intel engineers attended the same conferences as other company engineers, and read the same papers about performance enhancing strategies -- so it is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk."

He points out this will make it more difficult to develop kernel software, since "Suddenly the trickiest parts of a kernel need to do backflips to cope with problems deep in the micro-architecture." And he also complains that Intel "has been exceedingly clever to mix Meltdown (speculative loads) with a separate issue (Spectre). This is pulling the wool over the public's eyes..."

"It is a scandal, and I want repaired processors for free."
This discussion has been archived. No new comments can be posted.

OpenBSD's De Raadt Pans 'Incredibly Bad' Disclsoure of Intel CPU Bug

Comments Filter:
  • by Lisandro ( 799651 ) on Monday January 08, 2018 @07:43AM (#55884245)

    You know, he's not wrong. This is, in impact, way bigger than Intel's FDIV fiasco and that ended up in recalls.

    • Re: (Score:3, Funny)

      by Hal_Porter ( 817932 )

      Free i5s and i7s! I want to believe!

      • by TheDarkMaster ( 1292526 ) on Monday January 08, 2018 @08:22AM (#55884341)
        Replaced/repaired, not free. Having said that the problem will be how to replace processors that have become obsolete and therefore out of the market, and where you can not simply replace all the associated hardware to pick up a current and patched processor. And I suspect that most of those who can change the associated hardware will simply migrate to AMD instead of taking another Intel.
        • by Hal_Porter ( 817932 ) on Monday January 08, 2018 @09:07AM (#55884469)

          Oh I agree 1000%. It's not a freebie, it's Intel living up to the implicit contract to provide a CPU with the performance it was benchmarked when I bought it and not allow user mode stuff to read kernel memory.

          In the UK you could make an argument that a processor with that bug was 'not fit for purpose'. Of course it's in the US that a class action suit has the highest chance of success and outside the US Intel will probably follow the US lead.

          It'll be interesting to watch. Then again all my Intel chips are soldered to laptop motherboards. And rather elderly laptops at that - it's not like I'm going to convince Intel to convince Asus and Apple to recall motherboards that are out of warranty and do BGA rework to replace the CPUs.

          However if I had machines with socketed CPUs and I was in the US I'd join a class action suit. Mind you Intel will presumably claim KPTI and its equivalents on Windows and macOS fix the security problem and any change in performance doesn't violate any sort of contractual agreement. Which they may or may not get away with. I think they probably will.

    • by Anonymous Coward on Monday January 08, 2018 @08:09AM (#55884305)

      How far does the recall go? Should there just be a recall for Meltdown, or does that also extend to Spectre?

      There wasn't a software workaround for the FDIV bug, which is why there was a recall. The F00F bug did have a software workaround, which is why there wasn't a recall for that bug. Meltdown also has a software workaround, though one with a potentially significant performance hit. Meltdown seems more like the F00F bug in that respect. Arguably, Spectre is a better candidate for a recall than Meltdown. Although there is a software workaround for it (see retopline), it cannot be implemented just by patching the operating system.

      The problem here is that some of these features were designed over 20 years ago, when security wasn't as much of a priority. The feature worked and didn't present obvious security issues, so nobody tried to fix what didn't seem to be broken. It wouldn't surprise me at all if many other potentially serious vulnerabilities were lurking in hardware.

    • by Zocalo ( 252965 ) on Monday January 08, 2018 @08:29AM (#55884363) Homepage
      He's not wrong, both on the recall (which I'm not holding my breath on - I fully expect Intel to fight that to the bitter end given how much more painful than the Pentium replacements that would be for them) and the handling of the entire situation. There's clearly been a very high bar set betweeen those who were given the heads-up and those who were not, especially amongst service providers where it appears that only the *really* big players were in the loop. In the case of BSD devs specifically being left out of the loop though, perhaps Theo needs to take Linus' advice to Intel and a good hard look in the mirror as I seem to recall a similar incident not so long ago where the BSD devs were in the loop, but Theo refused to play ball and turned it into a free for all. I don't have the slightest problem with Theo standing up for his principles, but to do so without expecting there to be some rather obvious blowback should there be a similar situation in the future is rather naive, to say the least.
      • by Jody Bruchon ( 3404363 ) on Monday January 08, 2018 @09:37AM (#55884591)
        A recall of every CPU since 2006 would decimate (if the recall isn't heavily utilized) or likely even bankrupt Intel. The Core 2 generation is the oldest practical Intel CPU (yes, I know this is a subjective statement, thus "practical") on which you can run Windows 10 and modern software. Every computer running Windows 10 and an Intel chip would need CPU replacement. We are talking quite literally several billion processors since Intel sells a few hundred million per year. Intel's market cap is over 200 billion dollars, but even if they were expected to replace 1 billion $100 processors that's half of the company's value. Since we're talking about 11 years worth of processors there is potential for the number to be more like 3-4 billion processors. This is purely the financial side and ignores all of the logistics which would be a totally separate nightmare. Intel is incapable of manufacturing anywhere close to that many processors in a year ESPECIALLY if they continue to sell new processors while doing the recall.

        Intel simply cannot afford to recall all affected processors. Do not expect it to happen because it won't. They will obscurity-by-corporate-speak [youtube.com] their way out of this in a way that could make Enron's obfuscated lies look tame. If there were no software mitigation they would have few straws to grasp at, but the OS workarounds give them a tiny escape door and you better believe that they'll hire a whole crew of bulldozers to force this massve elephant through it.
        • by Zocalo ( 252965 )
          That's exactly my reasoning. By comparison the Pentium recall was easy; die and pin-out compatible CPUs were still in production, but even for a partial recall here it's likely Intel would have to not only dust off old silicon designs, but the associated fabrication processes and packages as well. And that's before you start to factor in the higher proportion of CPUs now that are not really end-user, or even workshop replaceable, because they are phyically attached to motherboards rather than socketed. T
        • by AmiMoJo ( 196126 )

          As I recall the Pentium recall was option, i.e. you had to contact them to get your CPU replaced rather than them actively contacting you.

          That seems like a reasonable way to handle it. Most people probably won't care enough to get their CPU replaced, but those who want the fix can get it. Of course it gets tricky with soldered on CPUs, for those they would just have to offer compensation.

        • by llZENll ( 545605 )

          What if they replace 1 billion $1 dollar processors? Because if you manufactured a processor from 10 years ago with todays technology, it would probably be in the $1 range... And they wouldn't even have to replace them for free, just give me an option, I would gladly pay $50-$100 to have a drop in replacement of my sandy bridge that used 20% of the power and probably didn't even need a heatsink that is manufactured with the latest technology, but they won't, because they know I'm forced to upgrade to a la

          • by networkBoy ( 774728 ) on Monday January 08, 2018 @01:16PM (#55885911) Journal

            Bwahahahahaaaa
            it doesn't work that way at all.

            Old designs would be for different process technologies. As the tech changes the DRCs (Design rule checks) change as well.

            You can't run a design on a process it wasn't made for, the resulting product simply won't work correctly (if at all).

            If the CPU was designed for a gate width of 35nM then it was designed with biasing around that gate width's leakage. If you then try to spin that part on a 14nM fab the biasing of the gates is all wrong and it will (likely catch fire) not work at all because of such high leakage.

            Additionally, price doesn't scale the way you imply. A wafer start costs about $1K. Doesn't matter what process you run on it (it does, but not really all that much). The cost per part is based on the number of functional parts per wafer at the end. Thus going from an 8 to a 12 inch wafer lowers cost even though the process change requires a $2.2bn fab to be built, you have gone from 201 sq inches to 452 square inches, over *double* the yield.
            Same thing from process shrinks, you cut the area used by your transistor gates and you make the die smaller, then you can fit more on a wafer.

            Thing is, Intel may not even have fabs capable of making the older parts any more, even if they wanted to. Process tech has evolved, IDK if they even have an 8" fabs left...

            To just "redesign" the part for the new process is not realistic either.

            TLDR: To make an old part will cost the same or more than it did when it was the latest and greatest.

        • I'm inclined to agree, and I suspect Intel will negotiate (in court?) to do a recall of (say) all the chips on a device still in warranty or some such. That way there's at least a reasonable way to do it in a practical sense. Having a recall that you can't actually perform isn't really going to help anyone.

          Not sure about the US, but in the UK there's provision in the law for stuff you couldn't possibly have known about. That is, let's say you make a teleporter and the world starts using it. If (in a few yea

    • by thegarbz ( 1787294 ) on Monday January 08, 2018 @08:34AM (#55884377)

      Isn't he? Firstly clearly the distribution was too wide as it was given there was a moratorium on disclosure scheduled for tomorrow to allow all patching to be in place in advance.

      Secondly he has in the past jumped the gun on responsible disclosure, parroting OpenBSD as the secure alternative patting himself on the back for being the first.

      Thirdly there are multiple groups now that refuse to work with him for this very reason. The OpenSSL team also disclosed to others before OpenBSD for the same reason.

      He shat in his bed, and now is complaining that he has to sleep in it.

      • Re: (Score:3, Insightful)

        by StormReaver ( 59959 )

        Firstly clearly the distribution was too wide as it was given there was a moratorium on disclosure scheduled for tomorrow to allow all patching to be in place in advance.

        You largely validated his posting with this one sentence. This is exactly what he's complaining about. How do you expect patching to be in place in advance for OpenBSD if the kernel developers weren't notified? Since OpenBSD isn't Tier-1, so they weren't notified. Apparently, only Microsoft was notified in advance, which is a clusterfuck so big, that should be reason enough to prove willful negligence by Intel.

        I completely agree with Theo.

        • by MSG ( 12810 ) on Monday January 08, 2018 @11:31AM (#55885255)

          How do you expect patching to be in place in advance for OpenBSD if the kernel developers weren't notified?

          You're missing the point. The OpenBSD team would be notified if they cooperated with the temporary embargoes that are in place to provide vendors time to patch before attacks are developed and deployed. They haven't, in the past, so they're no longer in the group that gets advance notice.

        • by thegarbz ( 1787294 ) on Monday January 08, 2018 @12:04PM (#55885461)

          You largely validated his posting with this one sentence. This is exactly what he's complaining about.

          And if you don't take that sentence out of context you'll have seen the point. What happened to OpenBSD and Theo is the fault of precisely one person: Theo.

          Hell when we discussed this on Slashdot there were a lot of posters saying that Theo's actions at the time would hurt the OpenBSD community as people would not disclose the vulnerabilities to them. Looks like they were right too.

          I agree the OpenBSD community is in a bad place. I also agree with Theo, but only in that his actions have spoken louder than his words.

    • by swb ( 14022 )

      I won't argue he's wrong, but I think as fast as CPUs change you'd have to have across the board reductions in workload capacity by a significant number (ie, the 30% touted initially) to be able to claim harm and justify a recall.

      So far what I've read is that performance in some storage applications has taken a small hit, but generally it's not a meaningful hit overall in CPU performance.

      And even if you could prove a performance hit, how reliable are the numbers? Workloads vary a lot. And if you're not op

      • Datacenters which already patched are apparently getting a performance hit in the high two-digits. Epic, for example, has people complaining [epicgames.com] because users cannot connect to game servers after the patch doubled servers CPU load.

        • by swb ( 14022 )

          It's hard to understand if this is Epic finding a convenient whipping boy for their problems or an actual problem associated with the patch. There's always complaining about gaming server performance, outages, etc, so it's not like they couldn't have other problems and that this is just being used as an excuse.

  • by segedunum ( 883035 ) on Monday January 08, 2018 @08:27AM (#55884355)
    This has been extremely worrying. What's more worrying are the number of 'security researchers' regurgitating Intel's bullshit verbatim. We have yet to fully see the fallout from this.

    He's also dead right in that Intel has been mixing up the two issues, Meltdown and Spectre, deliberately, so they could tell everyone that it wasn't just Intel that was affected, and they also gave the impression that Spectre had been fixed when it was Meltdown that had been mitigated - with a patch that creates unacceptable performance problems, to a lesser or a greater extent.

    Yes, all processor manufacturers are affected by Spectre, but it is Intel that is mostly affected because they implemented speculative loads badly without much attempt at segregation. They've also attempted to pass this off as 'historical architectural decisions we can do nothing about, but it is working as designed'.
    • by OneAhead ( 1495535 ) on Monday January 08, 2018 @11:02AM (#55885071)

      He's also dead right in that Intel has been mixing up the two issues, Meltdown and Spectre, deliberately, so they could tell everyone that it wasn't just Intel that was affected, and they also gave the impression that Spectre had been fixed when it was Meltdown that had been mitigated - with a patch that creates unacceptable performance problems, to a lesser or a greater extent.

      This, in spades. While Theo De Raadt is not my favorite IT personality, the mixing together of the issues (actually 3 of them!) has made it exceedingly hard for someone who isn't familiar with the inner working of modern CPU architectures to get the story straight, and Mr. De Raadt gets kudos for calling them out on it.

      The following is what I could infer from what I found online. I'm almost certain a good portion of it is WRONG, and I hope the more knowledgeable part of the /. crowd will help me out by correcting it. (No, I'm not being lazy - just stretched to the limit of my understanding of the primary sources [blogspot.be], yet desperate to gain some working understanding beyond the "it's hard to explain but you should apply patches" advice found everywhere on the internet.)

      • There are three separate but somewhat related issues:
        • Variant 1: bounds check bypass (CVE-2017-5753)
        • Variant 2: branch target injection (CVE-2017-5715)
        • Variant 3: rogue data cache load (CVE-2017-5754)
      • Variant 3 is a true bug by any definition. It was named "meltdown" and is an Intel exclusive - AMD and ARM are not affected. If an attacker succeeds to run a malicious binary on an affected system, they can read kernel memory, including juicy secrets like passwords and decription keys. To put this into perspective, this is very nearly as bad as a local privilege escalation. And to put that into perspective, local privilege escalations are so common that there's a mantra in security: if a sufficiently skilled adversary gains "arbitrary code execution", it's virtually "game over" and you can go scrub your HDD. Nevertheless, the aforementioned "sufficiently skilled" bar lies quite high and may not be met by a lot of common threats (especially the automated ones). So, from a defense-in-depth perspective, the only sane advise is "patch your system now". The big news is that patching will come with a performance impact that is proportional with how frequently a process calls the kernel. A process that simply allocates a big chunk of memory, loads data into it, and starts chewing on that (think stuff like compression, crypto mining, scientific computation,...) will not feel much impact, while databases generally will.
      • Variant 1, IF I understand correctly, allows an attacker to feed a non-buggy process carefully crafted input that tricks it into leaking data into memory space that is owned by the process in question, but not in use by it. The bad news here is that all CPUs (including AMD and ARM) are vulnerable and there's no way to patch it system-wide. One could argue that this is not a huge deal in and by itself because if the process and the system have no other bugs, the data could never be retrieved. However, it is apparently possible on certain browsers to make JavaScript read data from the "not-in-use" memory locations (which would be a feature for a "system" language like C, but I would classify it as a bug for a high-level interpreted language such as JavaScript). Given that a browser handles sensitive data (passwords), this is potentially devastating. Fortunately, it is easily mitigated by the fact that the leaked data doesn't live long by virtue of it physically only residing in the CPU cache and not the actual memory. The attack therefore relies on precise timing, and by decreasing the precision of the timing mechanisms that are available in JavaScript, browser manufacturers can put a stopgap into th
      • by Lothsahn ( 221388 ) <Lothsahn@@@SPAM_ ... u_bastardsyahocm> on Monday January 08, 2018 @11:56AM (#55885395)
        Thank you for noting that you're not 100% sure it's right, and for the excellent summary. There's a ton of misinformation going around, especially with 0100010001010011 dude on Slashdot repeatedly posting that Meltdown is INTEL ONLY, which is false, as some ARM products are affected. What is true is that Meltdown does not affect AMD and affects only a few of ARM's processors.

        As you state, it's important to rely on the original sources. Here is each CPU vendor's response to the security issues:
        https://www.amd.com/en/corpora... [amd.com]
        https://www.intel.com/content/... [intel.com]
        https://developer.arm.com/supp... [arm.com]

        Here are two corrections to make:
        1) Meltdown:
        One of your bold statements "AMD and ARM are not affected" is untrue. See here, from ARM directly:
        https://developer.arm.com/supp... [arm.com]

        ARM has confirmed that A75 is vulnerable to Meltdown. In addition, A15, A57, and A72 are vulnerable to a variant of Meltdown (Variant 3a) which ARM has added. ARM has stated that they believe this variant is NOT exploitable, however, there is already userspace code out there that can do some limited exploits:
        https://github.com/lgeek/spec_... [github.com]

        AMD is not affected by Meltdown, in any form. From AMD's press release:
        https://www.amd.com/en/corpora... [amd.com]

        2) Variant 1: While other vendors may require application changes to address this issue, AMD appears to be able to address this with an OS update, based on their post:
        https://www.amd.com/en/corpora... [amd.com]


        Summary:
        Variant 1: Some manufacturers (ARM) appear to not be able to fix it and are recommending compiler changes, but AMD will fix this in OS updates. Unclear how Intel is addressing this vulnerability.
        Variant 2: Correct, from what I can tell.
        Variant 3 (Meltdown): Affects nearly all Intel (within the last 10 years) and ARM A75 chips. AMD not affected.
        Variant 3a (Modified Meltdown): Affects a larger set of high performance ARM chips

        Finally, Intel has done a terrible job (intentionally?) at conflating the two issues, which is unfair. These are 3 separate security issues, with their own priorities and impacts. If you read Intel's official press release for this issue, there's no differentiation between variants 1-3, like there is for AMD and ARM:
        https://www.intel.com/content/... [intel.com]
      • by complete loony ( 663508 ) <Jeremy.Lakeman @ g m a il.com> on Monday January 08, 2018 @11:57AM (#55885407)

        I skimmed both papers, and that seems to about sum it up. Though I would add that all three attacks cause speculative execution of a construction like; "x = array[ *pointer ];", to push memory from an array into or out of cache based on the data loaded from the victim pointer. So combining the announcement does make some sense, as the details of any of those variants might point people to rediscovering the others.

        I was impressed with the work put into variant 2. Tricking the CPU branch predictor into running ROP-like gadgets within a higher privileged process, then using cache access timing to work out what happened. It almost sounds like bad sci-fi dialog, yet they actually did it. And yes, the attack complexity sounds comparable to similar ROP stack smashing exploits.

        Variant 2 is being patched in compilers. Both gcc and clang [llvm.org] are working on patches (that might already be released?) that avoid any speculative execution of indirect branching. Using a trick documented by google to patch the stack with the destination address, and then return. So now we just have to recompile *everything* that has access to privileged / sensitive memory contents to hopefully prevent attackers doing anything useful with branch poisoning. Of course there will be a performance hit, as no indirect branches can be correctly predicted.

        Personally I would say that the problem with variant 2 is sharing the branch predictor between domains. Branches taken in one process, influence how branches in other processes are predicted. I can understand that in a modern OS, multiple processes end up running the same library code, so this may have been a deliberate decision. But, if these tables were stored per-thread and context switched, this problem would probably have never been exploitable.

        The Spectre paper did suggest that they had found some evidence of something like variant 2 on an AMD CPU. But I believe that the inner workings of AMD's branch predictor are not as easily deduced as Intel's. So the researchers took the easiest route and attacked 3 different Intel cores instead. That doesn't mean that nobody will ever work out how to pull off an attack though.

  • Correction needed (Score:5, Informative)

    by fubarrr ( 884157 ) on Monday January 08, 2018 @08:28AM (#55884359)

    >is hard to believe they ignored the risky aspects. I bet they were instructed to ignore the risk

    The specific issue that Pentium line CPUs: a) do privilege check asynchronously; b) do it only for the "winning" execution branch was very well known among CPU design community.

    Intel architects even bragged about that as their "innovation" in industry journals and filled a number of patents for that (this is the reason amd privilege checker runs on all branches)

    • Re:Correction needed (Score:4, Interesting)

      by TheRaven64 ( 641858 ) on Monday January 08, 2018 @09:14AM (#55884499) Journal
      And when Intel did this, everyone was happy that the cost of system calls went down. Now everyone is saying that they secretly knew that it was a security issue and only an idiot would have implemented it.
      • System calls where always slow because they used to be called via a software interrupt call.

        SYSCALL is an in x64 instruction that speeds this up, introduced by AMD.

        Speculative execution predates SYSCALL by about 5 years.

        System calls are now slower because the kernel memory now has to be mapped and unmapped when the system call enters/leaves rather than be mapped all the time. This has to be done because memory that was marked as privledged can now be accessed by user programs i.e. memory protection no long

        • Re:Correction needed (Score:5, Informative)

          by TheRaven64 ( 641858 ) on Monday January 08, 2018 @11:00AM (#55885063) Journal

          System calls where always slow because they used to be called via a software interrupt call.

          And software interrupts were slow because they were not considered branches by early branch predictors and so triggered a complete pipeline flush equivalent to a branch mispredict (followed immediately by another branch, which SYSCALL removed). Intel addressed this by treating software interrupts as normal branches for the branch predictor, with an extra hint that they changed privilege level. This gave a small improvement to the Pentium, but was a huge boost on the Pentium 4, where the pipelines were long and deep enough that they had up to 140 instructions in flight at a time and having to flush all of those for a system call was painful.

          Speculative execution does n't mean we have have this problem, AMD managed to do it fine. No one can say this is by design, if it is by design then it should be documented since 1995 that the MMU protection can be bypassed.

          Speculative execution across ring changes is the root cause of this. AMD doesn't do this because Intel patented it, told AMD, and didn't include it in their cross-licensing agreement. You can bet that AMD was just waiting for the patent to expire before doing it, because without it you have to wait until all branches up to the system call have been retired before you can perform the transition. The MMU protection isn't bypassed, because the instructions that would be bypassing the MMU protection are cancelled. There is a side channel that allows you use the changes in cache behaviour to determine what the values in memory would have been.

    • That sounds like a potentially risky but not wholly inreasonable approach. The risk is that the process gains access to the results of a "losing" branch, either directly by using some exploit, or indirectly by using some weird timing attack or whatever. Isn't the real issue that such an attack turns out to be feasible?
    • If everyone knew it from the beginning, why has it taken 22-23 years for someone in the CPU design community to let software developers know there's this massive security hole?

  • Core issue is trust (Score:4, Interesting)

    by eyepeepackets ( 33477 ) on Monday January 08, 2018 @08:30AM (#55884365)

    Intel makes a monumental decision to benefit the short-term interest of their corporation at the long-term expense of their customers, then tries to weasel out of a equitable fix for their customers? It's not only their product that can't be trusted, it's their judgement at all levels. Heads need to roll at Intel for this....

    • by nanoflower ( 1077145 ) on Monday January 08, 2018 @08:39AM (#55884395)
      It was also a short and long term benefit of their customers. Are you willing to pay Intel back for the extra performance they provided by their same decision that you are deriding today?
      • by Christian Smith ( 3497 ) on Monday January 08, 2018 @09:43AM (#55884625) Homepage

        It was also a short and long term benefit of their customers. Are you willing to pay Intel back for the extra performance they provided by their same decision that you are deriding today?

        Eh? We've already paid the Intel for the performance. Intel CPUs are that bit more expensive than equivalent AMD CPUs, performance is why they commanded the price premium.

        Customers trusted Intel that the performance was gained with no cost to security, a reasonable assumption. I'm computer literate, and I'm shocked that this can even be an issue. How the hell do speculative memory accesses leak through kernel memory protection?

        So I'm not sure what you think is to be paid back.

    • Intel makes a monumental decision to benefit the short-term interest of their corporation at the long-term expense of their customers, then tries to weasel out of a equitable fix for their customers? It's not only their product that can't be trusted, it's their judgement at all levels. Heads need to roll at Intel for this....

      Intel's stock price is down about $2 US since this became known, so I don't think I'd bet much on heads rolling. The problem is that most of the world is not IT geeks and for those non-iT people, many of them are scared of AMD. They know nothing about CPUs, so to them Intel is the safe choice because only Intel advertises on TV. Oddly, this may actually increase their fear of AMD because, as pointed out, Intel has managed to convince everybody that all CPUs have both problems so non-IT people are likel

  • Dream on (Score:5, Interesting)

    by sjbe ( 173966 ) on Monday January 08, 2018 @08:31AM (#55884369)

    "It is a scandal, and I want repaired processors for free."

    And I want a pet unicorn. Come to think of it, unicorns are about as real a thing as a "repaired processor" since they physically cannot be repaired. He wants a replacement processor which almost certainly is never going to happen. Basically he's asking for every processor produced in the last 20 years to be replaced for free. If you think that's realistic I've got a bridge to sell you.

    There will be plenty of legal action over this and the results of that will be the full extend of any compensation. Furthermore to get compensation he will have to show actual harm incurred. Simple fact is that at least so far there has been little to no tangible harm from this problem to date so standing will be an issue for anyone who sues. This might change in the coming months/years but until it does the chip makers aren't going to pay a dime to replace anyone's chip - flawed or otherwise.

    • "It is a scandal, and I want repaired processors for free."

      And I want a pet unicorn. Come to think of it, unicorns are about as real a thing as a "repaired processor" since they physically cannot be repaired. He wants a replacement processor which almost certainly is never going to happen. Basically he's asking for every processor produced in the last 20 years to be replaced for free. If you think that's realistic I've got a bridge to sell you.

      Ironically, it is realistic for one obvious reason; consumers are fucking lazy.

      When you look at the actual affected processors vs. the number of people who will actually get off their ass and make a claim to have a processor replaced for free, it becomes very clear how affordable this really is. People are lazy, and don't give a shit. 75% of consumers won't even know or understand what the fuck "Meltdown" is a month from now, no matter how many times it's broken down in laymans terms on the evening news

      • When you look at the actual affected processors vs. the number of people who will actually get off their ass and make a claim to have a processor replaced for free, it becomes very clear how affordable this really is.

        A good point but not as good as you make it seem. Quite a lot of affected chips are not user serviceable for reasons such as being soldered to the board. This means that it isn't a simple matter of sending a customer a new chip. In many cases the boards in question won't be available for any price so the most a chipmaker could do would be to pay for a replacement. A repair simply isn't going to be an option in many cases.

        But you are right, 99.99999% of people will probably have forgotten about this in a

      • Replacing the CPU on on one host often puts every system in the rack at risk. Most household systems can stand a loss of a few % of performance with a patched kernel. Server rooms filled with racks and blades, such as a major data center hosts, can mean unscrambling rats' nests of cabling to extract a host, opening it up, edging blocking components out of the way, releasing the heat sinks, replacing the CPU, _replacing the thermal paste_, and re-attaching the heat sink, closing the system up, and testing

      • I wonder how many people actually requested a replacement processor from Intel back when they had a recalled the FDIV bug, and how many of those users actually replaced their processor once they got it. Are there any numbers out there on that? Replacing a CPU is a pain in the ass, so I wonder how many people went through the effort to do it.

      • I mean replacing a CPU is a non-trivial task in a desktop, nevermind impossible for laptops which are the majority of purchases. And even if you could find someone else to do it you have to give up your device while they do, and you can bet that won't be a quick procedure.

        How many components of your car, or washing machine, boiler, oven have *you* considered replacing? Even if you know what components there are in there, and what flaws they might have? Would you even know what particular components are in y

    • by sjames ( 1099 )

      Everyone running an intel CPU will suddenly discover that they have 5-30% less processor than they paid for. In many cases, that difference would have resulted in going with the AMD processor. That is a real economic harm that deserves compensation.

      That doesn't mean justice will be done, the courts often bend over backwards and grab their ankles for large corporations, but morally and ethically, Intel owes a lot of people a pile of cash.

      • Everyone running an intel CPU will suddenly discover that they have 5-30% less processor than they paid for.

        Untrue. The hardware is unchanged and can run exactly as fast as it always did. Security updates and software slow machines all the time. You'll have to credibly explain why this case requires special consideration. Easy to claim here but not so easy in front of a judge. Frankly most people aren't even going to notice and the few that do notice are going to be corner cases, mostly in large corporations with adequate resources to deal with the problem. From a 10,000 foot view it's not clear why this is

    • He wants a replacement processor which almost certainly is never going to happen. Basically he's asking for every processor produced in the last 20 years to be replaced for free. If you think that's realistic I've got a bridge to sell you.

      How is this different (aside from magnitude/number of units sold) from Takata's airbag recall? I wasn't affected by an exploding airbag, but I still get new airbags in my Dodge. Interestingly, it's apparently still going on [usatoday.com]

      I suspect a recall this large would bankrupt Intel, much like the airbag recall is bankrupting Takata. We've seen our automakers get bailed out because they were deemed "too big to fail", but maybe Intel failing could be a good thing (though I don't know of anyone that can simply step up

      • How is this different (aside from magnitude/number of units sold) from Takata's airbag recall?

        Nobody is going to die from this mistake. Pretty big and important difference there. Product defects that result in actual provable fatalities tend to get a lot more scrutiny.

        I suspect a recall this large would bankrupt Intel, much like the airbag recall is bankrupting Takata.

        Won't happen and while this is a serious issue, it isn't THAT serious. I expect Intel will pay some cash to settle some class action lawsuits (and so will some other chipmakers) but that's probably about as far as it will go unless there are revelations we haven't heard yet.

    • by Kythe ( 4779 )
      Don't be so sure Intel won't feel the need to make customers whole on this.

      It's a single data point, but an interesting one: Engaget's Facebook page posted yesterday about Intel's new processors with AMD graphics. Every single comment below the post asked why on Earth anyone would buy an Intel processor without any assurances the Meltdown/Spectre flaws were taken care of.

      The fallout hasn't even begun to really hit on this.
  • "... I want repaired processors for free."

    So do I. I want backdoor-free processors without payment. I will send Intel the faulty processors.

    Intel CPU Backdoor Report (Jan. 1, 2018) [slashdot.org]

    My opinion: Intel is a world-class company, with poor top-level management. Brian Krzanich is not the kind of person who is necessary. He is not a person with enthusiasm for technology combined with the social ability to lead a large company. One story about Krzanich: Intel CEO sold all the stock he could after Intel learned of security bug [arstechnica.com].

    Paul Otellini, the previous CEO, was worse, in my opinion. Otellini "joined the finance department in 1974 [mercurynews.com]" I complained about Otellini 11 1/2 years ago in a Slashdot comment: More Intel employees should say in public what they have told me in private: Intel CEO Paul Otellini is not a competent leader. He lacks social ability. [slashdot.org] (June 09, 2006)"

    Intel's health and strength is important to everyone on the planet, it seems to me. The technological part of the company can be excellent, but recent top management has not been able to handle the challenges.

    The underlying issue, it seems to me, is that the process of choosing new CEOs tends to be defective. Perhaps all employees should have 50% of a vote, with the board of directors having 50%.
  • Fuck intel! (Score:3, Interesting)

    by Anonymous Coward on Monday January 08, 2018 @08:55AM (#55884437)

    I dont care how much better their next CPUs might be, im jumping ship for AMD on my next upgrade. I did the same after NVidia fucked me over.

  • by Misagon ( 1135 ) on Monday January 08, 2018 @09:14AM (#55884493)

    I was one of those who called "no way" at first, but just yesterday I found this quote [danluu.com] from an Intel engineer. It was originally posted in a reddit thread [reddit.com] but has since been deleted - but not before being confirmed by other former engineers at Intel.

    As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.

    Why?

    Let me set the scene: It's late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times... we can't live forever in the shadow of the early 90's FDIV bug, we need to move on. Our competition is moving much faster than we are" - I'm paraphrasing. Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn't explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signalled a sea change at Intel to many of us who were there. And it didn't seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.

    • If I may, I'd have to call this an anecdote rather than a quote. The description is from years after the Intel meeting, and doesn't have direct quotes of speech or writing of the personnel involved in the policy change.

      With that understood about the anecdote's provenance, it is _completely_ believable. It is precisely the sort of mandate that can save a company in the short term, preserving the jobs and careers and technological development the company is doing, at the risk of a deadly failure down the road

  • As others have previously, it is now time for a completely open processor. I like the work of openrisc and risc v projects. In my opinion, Intel is standing at the precipice of its own undoing. Intel's steadfast refusal to issue a recall is just hubris and might be a call to arms for competition to knock it down. This year might very well be the year that a few kickstarter projects get launched and that we have the beginnings of an exciting new trend in computing.
  • Not to be an Intel apologist, but clearly they can't afford to replace everyone's Intel with an identical socket that is unaffected by the problem. The best I'd think that could be hoped for would be a refund with depreciation of value on the processor. That'd still suck but I can't see how we'd get any more. A class action would just get us all a $15 coupon towards our next Intel purchase.
    • "clearly they can't afford to replace everyone's Intel with an identical socket that is unaffected by the problem."

      Why do people say this? Intel is sitting on $17 BILLION in cash. Intel apologists are incredible.
    • by AHuxley ( 892839 )
      Re "... with an identical socket that is unaffected by the problem."
      All we can do is wait for the next CPU and see if better testing was done.
      Then upgrade.
      The global buying cycle of CPU upgrading has a few options:
      For people who play computer games and need a fast CPU:
      Trust the same brand to get a new CPU thats works next time.
      Try another existing brand that has a different, new CPU that is tested and reward them.

      Want security and know to walk away form the brands that fail?
      Find, create a better
    • I seem to recall that a processor without a coprocessor was one with it, but with the coprocessor burned away. Would it be possible to burn away the management engine?
  • I'm no fan of Intel but I can't help but see Meltdown as at least partly the fault of OS vendors. They decided to keep kernel and user memory in the same address space for performance despite known problems with branch prediction and despite KPTI being an option.

    I doubt Intel ever claimed prediction could not be detected nor forced kernel devs not to use KPTI. Usually when a vulnerability is found in a software architecture you blame the software.

Who goeth a-borrowing goeth a-sorrowing. -- Thomas Tusser

Working...