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.

372 comments

  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 Megol · · Score: 1

      As the AC correctly points out bugs are to be expected and are known to exist. Just read the amount of "will not fix" erratas published by Intel and realize that most erratas that will get fixed will be in later revisions (steppings) and not in currently available chips. The things that do get fixed in released systems are things microcode or feature control hardware can touch.

      This isn't unique to Intel of course.

    2. Re:It isn't his decision by mysidia · · Score: 2, Interesting

      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.

      It turns out that these new methods of attack affect AMD x86 CPUs, and ARM non-x86 CPUs as well,
      so it's a multi-platform weakness that the only hardware safe against are essentially iPad and iPhone.

      Someone may TRY to sue Intel over this, but I suspect they will not be successful, since this
      isn't defective hardware per se, but hardware that doesn't resist a new kind of attack method.

      So from a warranty standpoint -- the CPUs are not defective, they perform as promised, but are just vulnerable to unforseen issues which are Not specific to the way Intel's CPUs are made BUT are general to the way almost All CPUs are made by ALL the manufacturers.

      You DON'T always get a free upgrade to your hardware when new unforseeable attack methods are discovered.
      Instead, sorry, but if your security requirements necessitate a hardware change, then you're going to have to pay for it, and don't expect a massive charity from Intel.

    3. Re:It isn't his decision by Anonymous Coward · · Score: 0

      WARNING! Don't click on any cdreimer links! WannaCry virus in links!!!

      One of my leg humping trolls hacked my Slashdot account during the holidays!

      Slashdot management has been notified!

    4. Re:It isn't his decision by 110010001000 · · Score: 2

      This isn't a simple errata. This is HUGE flaw, a true game changer. It is a flaw that CANNOT BE FIXED, only mitigated to some extent.

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

      It matters to me because I ride the bus with the people who pick up the trash of the Intel CEO. And I work hard to keep my country safe working in Government IT for $50,000 a year in Silicon Valley. The world revolves around me. We aren't all rich here in Silicon Valley.

    6. 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.

    7. Re:It isn't his decision by Anonymous Coward · · Score: 0

      It turns out that these new methods of attack affect AMD x86 CPUs, and ARM non-x86 CPUs as well,
      so it's a multi-platform weakness that the only hardware safe against are essentially iPad and iPhone.

      Yeah, about that...
      Meltdown and Spectre: All Macs, iPhones and iPads affected

    8. Re:It isn't his decision by mysidia · · Score: 2, Informative

      WRONG. The Meltdown attack ONLY AFFECTS INTEL

      False; Non-Intel platforms are affected by the same form of problems. The security issue related to Processor Speculation has been Acknowledged by ARM,
      and furthermore, even the Meltdown paper points out the same issues existing with at least several example attacks working reliably on the ARM and AMD platforms regarding out-of-order executions And instructions past illegal memory accesses.

    9. 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.

    10. Re:It isn't his decision by thegreatbob · · Score: 1

      There are some specific (very high-end) ARMs that are vulnerable as well.

      --
      There is no XUL, only WebExtensions...
    11. Re:It isn't his decision by mwvdlee · · Score: 0

      Please don't spread your own lie.
      ARM has publically stated a number of their CPU designs are affected by these bugs.
      Only AMD is denying.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    12. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Not sure why you're bragging. When you make $50K per year in Silicon Valley, you're near the poverty level.

    13. Re:It isn't his decision by 110010001000 · · Score: 1

      Wrong. Meltdown is not fixable, it can only be mitigated. And he sold his stock all last year. The last stock sale was in November, before this went public. Why are people lying for Intel?

    14. Re:It isn't his decision by Anonymous Coward · · Score: 0

      110010001000 has been bragging about this for months.

    15. Re:It isn't his decision by 110010001000 · · Score: 1

      Why do you continue to conflate the issues? There are multiple issues here. Meltdown is INTEL ONLY. Stop lying.

    16. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Oh, is he also a successful middle-aged YouTuber with 30 revenue streams?

    17. Re:It isn't his decision by stevelinton · · Score: 1

      Citation please

    18. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Who isn't these days?

    19. Re:It isn't his decision by Ash-Fox · · Score: 1

      No, let him continue. I want to see where this goes.

      --
      Change is certain; progress is not obligatory.
    20. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Creimer has a guaranteed five year contract in government IT. Nothing in the private sector is ever guaranteed.

    21. 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?

    22. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Then I wonder why creimer, I mean Chris, I mean you, I mean "he", spends all your time with private sector things like "investing" in silver and writing ebooks that are never published?

    23. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Bullshit! AMD is entirely unscathed with any performance issues.

      https://www.amd.com/en/corporate/speculative-execution

    24. 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

    25. Re:It isn't his decision by Anonymous Coward · · Score: 0

      If you focused on your career a few years ago you could have made all 5 years of money in 1 year by now

    26. Re:It isn't his decision by Anonymous Coward · · Score: 0

      He's not bragging, though.

    27. Re:It isn't his decision by Anonymous Coward · · Score: 0

      your very bitter at every intel bit of news ever across many threads, what did intel do to you, did its ceo run over your dog/cat/wife?

    28. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Incorrect . Intel alone is affected by the MELTDOWN bug. Other vendors are only affected by the SPECTRE bug. (Intel gets both! A Winner Is Them!)

      MELTDOWN is mitigated by kernel page table isolation (KPTI), and all of the major OS vendors are scrambling to implement a software workaround for this. AMD has already confirmed that their CPU architectures don't fall prey to this. The same goes for most ARM and all PPC, MIPS, Alpha, Sparc, etc. The few affected ARM designs are Intel-produced variants, and are not commonly found in the wild. KPTI, as a fix, is undesirable because it has a huge overhead that causes a massive performance hit. Additionally, it's not clear whether the fixes applied to various OSes (Linux excepted, since AMD themselves committed the patch to exclude AMD from using it) will be selective about applying KPTI. For all of the comments about "I'm gonna buy a Ryzen!", there's no guarantee that Windows will differentiate between Intel and AMD when activating KPTI.

      SPECTRE is a completely different beast. It affects everything and will take decades to weed out all of the chip designs vulnerable to it. In the meantime, the software workarounds are, by all reports, nowhere near as heavy-hitting as KPTI.

    29. Re:It isn't his decision by funny_smell · · Score: 2

      Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

      Here, FTFY.

    30. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Who? Creimer, that's who. Chris, you're a perpetual entertainment machine, you know that?

      One thing you're not, though, is successful.

    31. Re:It isn't his decision by Anonymous Coward · · Score: 1

      Currently, we have only verified Meltdown on Intel processors.

      That means they haven't verified Meltdown on AMD processors. So they could be affected, or not.

    32. Re: It isn't his decision by Type44Q · · Score: 1

      Good thing he sold all his stock before this went public.

      Good for the SEC investigators' job security, you mean.

    33. Re:It isn't his decision by Anonymous Coward · · Score: 0

      You could have been an idiot or not. That does not mean you are an idiot, right?

    34. Re:It isn't his decision by davros74 · · Score: 1

      Meltdown is more serious, but the mitigation is straight forward with some degree of performance degradation.

      Spectre is entirely different. The mitigation to the bounds check bypass requires examing and modifying source code, and recompiling binaries and libraries with special compiler settings. There is no magic quick fix on the software side for Spectre, since examing, recompiling and re-releasing all known software in the world is intractable.

      A hardware fix in future CPUs for this is harder but not impossible. It is harder in that the only sure way to eliminate the vector is to remove performance enhancements like speculative execution and branch prediction, but that's a major feature of all modern processors. How to make these features secure and keep most of the performance gains will be a hot area of future research. The 80486 is slow, but does not suffer from these issues. (Who wants to go back to 1990 performance levels?)

    35. Re:It isn't his decision by sexconker · · Score: 1

      ONLY the Cortex A75.

    36. Re:It isn't his decision by sexconker · · Score: 1

      "A number" being one. The Cortex A75.

    37. Re:It isn't his decision by Anonymous Coward · · Score: 1

      There is a difference between unclear and 'INTEL ONLY ISSUE'. Unclear means that they have insufficient evidence to say whether or not other processors are affected. It doesn't mean that the other processors are unaffected.

    38. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Is your shift key broke, bro?

    39. Re: It isn't his decision by Anonymous Coward · · Score: 0

      If you read the archived job postings by Intel Corp for, if I remember correctly, "Social Media Strategist" Slashdot was specifically mentioned in the past.

      Given that knowledge, the odds of paid Intel posters on these type of articles now are extremely likely.

    40. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Yess my Itanium is safe!

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

      No. ARM has confirmed that Meltdown (i.e., Variant 3 and 3a) also affects some of their processors.
      https://developer.arm.com/supp...

      Please stop lying. You are a despicable liar.

    42. Re:It isn't his decision by Anonymous Coward · · Score: 0

      creimer isn't in it for the money. creimer is an artist, a tortured genius who is working on his ebook of haiku about cats licking balls on public transit.

    43. Re:It isn't his decision by Anonymous Coward · · Score: 0

      No. The A-15, A-57, and A-72 are also vulnerable to a variant of Meltdown.
      https://developer.arm.com/supp...

    44. Re:It isn't his decision by mysidia · · Score: 3, Informative

      That is not contradictory information; it is just out of date. "Currently [as of the time the paper was written], we have only verified Meltdown on Intel processors.

      The information cited does NOT support your claim that Meltdown is Intel Only; nor were the authors even claiming they believed Meltdown to be Intel-Only --- the authors showed information to indicate AMD/ARM would also be vulnerable, but they were primarily interested at the time in demonstrating the exploit on Intel processors and made minimal at best efforts to fully demonstrate and exposit the problem on ARM/AMD despite showing these affected.

      Current security bulletins include more up-to-date information than the Authors' whitepaper.

    45. Re:It isn't his decision by Anonymous Coward · · Score: 0

      I work hard to keep my country safe working in Government IT for $50,000 a year in Silicon Valley.

      So why don't you get a better job?

    46. Re:It isn't his decision by Anonymous Coward · · Score: 0

      A number being 4: A75 A72 A57 and A15

    47. Re:It isn't his decision by Joce640k · · Score: 1

      You don't want your CPU secure? don't install the software patch and it'll continue to work exactly as it did.

      Good luck with that on Windows/Apple. You don't control updates there.

      --
      No sig today...
    48. Re:It isn't his decision by thegarbz · · Score: 2

      Why quote some 3rd party FAQ rather than the original paper which is linked to in your citation?:

      The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

    49. Re:It isn't his decision by Anonymous Coward · · Score: 0

      There is a difference between unclear and 'INTEL ONLY ISSUE'.

      Well shit dude, this sounds like fertile ground for a bunch of really, really smart security researchers to investigate. But I'm sure they all have better things to do - there probably isn't much incentive for them to work really hard at bringing "clarity" to the situation.

      Anyway, the topic is about what we "know right now" on January 5, 2018. We're not talking about "what we might know a month from now" or "what could happen but we actually have no proof about". We're not talking about "what's unclear". If someone has clarity, RIGHT NOW, that this specific issue is NOT Intel-only, then speak up about the facts. Don't disingenuously pussyfoot around about "what's unclear". People are spreading deliberate lies that there is factual published knowledge as of NOW that it is not an Intel-only issue, and those LIES are why we're discussing what is clear and factually documented NOW.

    50. Re:It isn't his decision by ravenshrike · · Score: 1

      Intel was officially notified of the flaw in June by Google. He filed his stock sale plans in late October. I would find it EXTREMELY hard to believe that a flaw of this magnitude was concealed from the CEO for more than 4 and a 1/2 months.

    51. Re:It isn't his decision by strikethree · · Score: 1

      Wow. So many ignorant people here.

      AMD checks the permissions BEFORE allowing access to the cache, Intel does not; therefore Meltdown is REALLY Intel only.

      The whole reason Spectre is even being discussed is to cause confusion in people who are not aware of the technical details (most everyone).

      Yes, you can cause AMD chips to speculatively execute but you can not get at the fucking data. It really is that simple. There is no amount of tweaking or hacking that will cause the AMD chip to cough up information like you can with Intel chips.

      This bug is actually apocalyptic in nature. Intel could get broken as a company. The only solution besides replacing the silicon is to flush the cache which is going to hit I/O intensive workloads MUCH harder than normal workloads.

      What is I/O intensive? Databases and Web Servers... Business are going to have double their capacity to deal with this patch. There will be lawsuits. Unless the administration hands Intel a Get Out of Jail Free card, Intel is going to get hurt BADLY.

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
    52. Re: It isn't his decision by Anonymous Coward · · Score: 0

      https://www.amd.com/en/corporate/speculative-execution

    53. Re:It isn't his decision by mwvdlee · · Score: 1

      https://developer.arm.com/supp...

      And also R7, R8, A8, A9, A17 and A73

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    54. Re:It isn't his decision by mwvdlee · · Score: 1

      Because ARM itself claims they are affected: https://developer.arm.com/supp...
      AMD also claims one variant of the bug affects their CPU's: https://www.amd.com/en/corpora...

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    55. Re: It isn't his decision by Anonymous Coward · · Score: 0

      In other words, AMD's chips are vulnerable to SPECTRE, but not to MELTDOWN.

    56. Re:It isn't his decision by Anonymous Coward · · Score: 0

      but this isn't just Intel. It's a fundamental architecture design issue for all processors including ARM and AMD.
      It has to do with the way speculative executions are run and the cache/registers used for the spec execution can be read (and injected) arbitrarily.

    57. Re:It isn't his decision by eric_harris_76 · · Score: 1

      Where did you read that?

      What I read on the subject said that he exercised his stock options, then sold all but 250,000 shares. He is required to own at least that many, by a certain date. IIRC correctly, March of this year or next year.

      Or was that "all" hyperbole, for effect?

      --
      There's no time like the present. Well, the past used to be.
    58. Re:It isn't his decision by Waccoon · · Score: 1

      I'm cynical by nature, but I still believe in innocent until proven guilty. Or, in more scientific contexts, I don't believe in invisible dragons in basements.

      Until the problem is demonstrated on AMD hardware, it's possible, but currently does not exist.

    59. Re:It isn't his decision by mysidia · · Score: 1

      AMD checks the permissions BEFORE allowing access to the cache, Intel does not; therefore Meltdown is REALLY Intel only.

      Apparently not; AMD is already known to be vulnerable to the bounds check bypass (CVE-2017-5753),
      so supposedly "checking permissions" before allowing access to cache didn't stop that.

      The only question is does AMD have any kind of equivalent to the other issues --- the next dominos that fall over
      to further exacerbate and make Intel and some other platforms have especially high risk of attack,
      branch target injection (CVE-2017-5715), and then rogue data cache load (CVE-2017-5754)

      For the second... it seems probable. That doesn't necessarily mean an equivalent to rogue data cache load will be found.

      As far as I know a heavy search, at least by the good guys, is Not underway; AMD will be presumed vulnerable only to the
      Bounds Check Bypass variant of Meltdown, for now.

      That doesn't mean we should not assume there is a major risk here until the mitigations are in place for at least the first variant, and a more definitive assurance is made that the AMD issues especially regarding 'bound check bypass CVE-2017-5715' the most pervasive and difficult to fully close hole is completely patched ---- yeah Meltdown issues variant 2 and variant 3 will get the spotlight, but OS kernel changes can deal with those two variants But not the Variant 1 attack that has been reported as affecting AMD procs for sure.

    60. Re: It isn't his decision by Anonymous Coward · · Score: 0

      ...except for the ones that are also susceptible to Meltdown.

    61. Re:It isn't his decision by Anonymous Coward · · Score: 0

      Good luck with that on Windows [...]. You don't control updates there.

      Fixed that for you; you made that shit up about Apple.

    62. Re:It isn't his decision by mysidia · · Score: 1

      Meltdown is more serious, but the mitigation is straight forward with some degree of performance degradation.

      I would say the word is acute. Meltdown is extremely acute because of the ease of quick results from exploitation but less serious overall than Spectre, because Meltdown will be easily addressed systematically by patches.... apply the patches, and the realistic concerns are mostly gone (although the current fixes have been rushed out too quickly and are thus causing major problems).

      Spectre is more serious because it represents a major issue where process' can be made to leak sensitive credentials across boundaries, that is basically going to have the only option being hardware changes to fix fully.

      If lawsuits will result against any chip manufacturers; probably Spectre will be the largest concern, although it's possible for some users the Meltdown fix has a particularly grievous affect on system performance, that seems less likely to be a class action situation.

  2. We'll see about that... by Anonymous Coward · · Score: 0

    The FDIV recall occurred after much backlash against Intel. If it turns out that Meltdown is exploited on a large enough scale to cause significant damage, or if the performance losses from implementing KPTI are severe enough, Intel may well change its position. Right now, it's nary a story at all because of the 24/7 focus on all things Trump. If people start getting angry due to their systems slowing, a recall might be in order. Intel is simply trying to avoid effectively recalling every non-Itanium processor they've made over the last 2+ decades (or even the last five years if the limit it to non-EOL products), because it would be quite expensive. This is far more widespread than FDIV, but if the impacts are serious enough, it might be the less damaging choice for Intel.

  3. Same syndrome as VW by Archtech · · Score: 4, Interesting

    The underlying pattern is exactly the same as the VW scandal. A manufacturer tries to deliver the promised performance, and in order to do so fakes out an emissions test (VW) or builds in a highly insecure procedure (Intel).

    At an even simpler level, it is just the battle between quality and quantity. VW and Intel cheated "a little" to provide the promised performance. We can expect a very great deal more of this.

    --
    I am sure that there are many other solipsists out there.
    1. Re:Same syndrome as VW by Archtech · · Score: 4, Interesting

      Intel will no doubt copy the big banks by claiming that it is "too big to fail". It would argue that it can't afford to replace all the defective chips, and so it shouldn't be forced to.

      The US government regards Intel as a huge asset - just like Microsoft, Oracle, IBM, Google, Facebook, Twitter, etc. - and will certainly take the company's side if it faces a serious threat to its existence.

      --
      I am sure that there are many other solipsists out there.
    2. Re:Same syndrome as VW by volodymyrbiryuk · · Score: 1

      True, but Intel is an American company so no big deal. It's only bad if the others do it. So don't expect anyone from Intel to be jailed like the VW guy. The only way is probably a class action lawsuit.

      --
      sudo rm -r -f --no-preserve-root /
    3. Re:Same syndrome as VW by Mordaximus · · Score: 1

      The underlying pattern is exactly the same as the VW scandal. A manufacturer tries to deliver the promised performance, and in order to do so fakes out an emissions test (VW) or builds in a highly insecure procedure (Intel).

      At an even simpler level, it is just the battle between quality and quantity. VW and Intel cheated "a little" to provide the promised performance. We can expect a very great deal more of this.

      This is not an Intel only problem; It's a fundamental design flaw (or oversight) that affects most modern processors. While Intel is taking the bulk of the blame on this, my take is this could very well be a catastrophe for smartphones, where each additional clock doesn't just affect performance. Losing a couple of hours a day of battery is pretty significant and quite possible.

    4. Re:Same syndrome as VW by Anonymous Coward · · Score: 1

      you forgot to change accounts before replying to yourself

    5. 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.

    6. Re:Same syndrome as VW by squiggleslash · · Score: 1

      Wait, you're saying Intel did this knowing it was a security risk?

      I've not heard that allegation even from Intel's strongest critics. Where is the evidence for this?

      --
      You are not alone. This is not normal. None of this is normal.
    7. Re:Same syndrome as VW by Anonymous Coward · · Score: 1

      I wouldn't say they did it knowing there were security concerns, but yes, everyone knew it was risky engineering. That it took over twenty years for somebody to discover an exploit shows just how small a risk, but it was a non-zero value, and everyone knew it.

      Where this differs from the VW scandal is that the risk VW gambled on concerned whether or not they could successfully trick regulators and do an end-run around existing laws, making it a criminal endeavor. Intel was just weighing security against performance, and eventually lost the bet. The difference is intent.

    8. Re:Same syndrome as VW by nagora · · Score: 2

      This is not an Intel only problem; It's a fundamental design flaw (or oversight) that affects most modern processors. While Intel is taking the bulk of the blame on this, my take is this could very well be a catastrophe for smartphones, where each additional clock doesn't just affect performance. Losing a couple of hours a day of battery is pretty significant and quite possible.

      There are two issues: Meltdown, which is easyish to exploit and affects all post-1995 Intel processors and 4, count 'em 4 Arm processors. Then there's Spectre which is hard to exploit and affects some other processors, but mostly Intel. Intel want everyone to believe that this means every vendor's in the same boat. They've done a very good job at this pretence but it is still a pretence. Or, "lie" if you prefer.

      --
      "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
    9. 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.

    10. Re:Same syndrome as VW by Stormy+Dragon · · Score: 4, Interesting

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

      So yes, Intel knowingly did this, for at least the last seven months.

    11. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      This is going to eat into performance that people had already paid for. It's bad enough for individual users, but imagine a huge facility like a cloud computing warehouse full of servers. Even a 5% hit is money straight out of their pockets. Intel is going to get sued for the bill.

      The least they could do is grant us peons the dubious benefit of a discount on future product if we own an old defective one that's about to get downgraded, performance-wise. They need to make the corporate decision to forget about profits this year and work on maintaining their market by giving people some kind of compensation, even if it is token.

    12. Re:Same syndrome as VW by thegarbz · · Score: 1

      The underlying pattern is exactly the same as the VW scandal. A manufacturer tries to deliver the promised performance, and in order to do so fakes out an emissions test (VW) or builds in a highly insecure procedure (Intel).

      At an even simpler level, it is just the battle between quality and quantity. VW and Intel cheated "a little" to provide the promised performance. We can expect a very great deal more of this.

      Wow. So basically your line of thinking is: "Company did something that turned out to be bad. Another company did something that turned out to be bad. Therefore conspiracy!!!!!!"

      Please use that grey matter between your ears to maybe read up on the VW scandal and this issue here before you look any more stupid than you already made yourself out to be with this post.

    13. Re:Same syndrome as VW by Anonymous Coward · · Score: 0


      The underlying pattern is exactly the same as the VW scandal.

      It's completely unlike the VW scandal. VW actively conspired to break the law, then actively conspired to hide that fact for months once they feared discovery. Intel just made an honest mistake. Intel screwed up, but they didn't try to hide it, haven't lied about it, and have worked with everyone to fix it.

      I'd agree they should be doing more to fix it, and the performance hits for the mitigation aren't going to be small in some cases. But no, it's nothing like the VW scandal at all.

    14. Re:Same syndrome as VW by NicknameUnavailable · · Score: 2

      This is not an Intel only problem; It's a fundamental design flaw (or oversight) that affects most modern processors.

      Meltdown is the Intel-specific bug (it's different and can be patched, at a 70% performance hit.) Spectre is an architectural issue in all modern chips that can't be fixed without redesigning them from the ground up. Intel is taking the heat for Meltdown because it reeks of extraordinarily sloppy design and/or an attempt to cheat and have the best benchmarks by making an insecure chip. I'm sure to them it wasn't even that big of a deal, they know their chips are all backdoored with Intel ME, so what's one little security flaw for a 333% performance boost capable of making them competitive with AMD?

    15. Re:Same syndrome as VW by Smidge204 · · Score: 1

      I don't know that much about CPU design and fabrication but it's my understanding that the manufacturing process takes several months at least, so assuming they discovered the flaw in June and managed to *immediately* change the design to fix it, implementing those changes to the production line the very next day, it quite possibly could still have taken months for the revised designs to make it into the factory doors.

      But after you consider that coming up with a fix might itself take weeks at least, and implementing those changes weeks to months all on its own (to be sure it fixes the problem and doesn't create new ones), it will probably be quite a while longer yet until this is resolved.
      =Smidge=

    16. Re:Same syndrome as VW by 110010001000 · · Score: 1

      So? That isn't an excuse to continue to sell a defective product!

    17. Re:Same syndrome as VW by jopsen · · Score: 1

      True, but Intel is an American company so no big deal. It's only bad if the others do it. So don't expect anyone from Intel to be jailed like the VW guy. The only way is probably a class action lawsuit.

      Okay, do we have any one indicating that this was intended... I think it's pretty clear that these are unintended bugs...
      Meltdown could justify a recall, but probably it's impractical to do this... and spectre will probably not even be fixed in new chips. I suspect it'll be some time before we have a reliable fix to spectre, it'll probably require changes to the specifications as well..

    18. Re:Same syndrome as VW by bobbied · · Score: 1

      The underlying pattern is exactly the same as the VW scandal. A manufacturer tries to deliver the promised performance, and in order to do so fakes out an emissions test (VW) or builds in a highly insecure procedure (Intel).

      At an even simpler level, it is just the battle between quality and quantity. VW and Intel cheated "a little" to provide the promised performance. We can expect a very great deal more of this.

      The problem with this comparison with VW's emission hack is that Intel isn't guilty of falsifying the results of some government mandated test. They just released a product with a security flaw, which was only recently discovered. It's like somebody figured out that a blank uncut key would open any VW car door. Yea, the customers are going to be upset, but it's not like it's going to affect your safety driving down the road and no laws where broken in the process.

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    19. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      Intel took a conscious design decision to do an important security check later, rather than earlier, and that decision a) Improved performance and b) Led to Mletdown

      It's like designing a supposedly secure application, where you sign on, get a menu, and select an option. But you don't validate the userid until after the menu is displayed. You do it when the first selection is made; then you throw invalid users out of the system. But this is fine because they still get thrown out.
      Then it turns out there's a hidden menu option...

      They *deliberately* broke a golden rule of security (check and deny access at the earliest opportunity), in order to get better performance. AMD *did not do this*.

      TLDR: Intel deliberately ignored security to gain performance.

      BTW I swear this thread (and all the others on this topic) are postively *infested* with Intel shills.

    20. Re:Same syndrome as VW by thegarbz · · Score: 1

      Intel will no doubt copy the big banks by claiming that it is "too big to fail". It would argue that it can't afford to replace all the defective chips, and so it shouldn't be forced to.

      Are you mental? In what world would they need to?

      a) there's software workarounds so there's no case at all to replace defective chips.
      b) the performance hit will drive an increase in sales as datacentres make up the shortfall.

      All the doom and gloom for Intel you people come up with is incredible. Just because you will something doesn't mean the world will work the way you think. Intel will be just fine in the happy little free market without any "too big to fail" bullshit.

    21. Re:Same syndrome as VW by thegarbz · · Score: 1

      It found out about the bug in June and continued to sell defective processors that requires a software fix.

      FTFY. What you're describing is called "business as normal" in the silicon world.

    22. Re:Same syndrome as VW by thegarbz · · Score: 1

      It found out about the bug in June and continued to sell defective processors that requires a software fix.

      FTFY. What you're describing is called "business as normal" in the silicon world. It is literally the norm, or have you never heard of erratas?

    23. Re:Same syndrome as VW by ravenshrike · · Score: 1

      We'll know if Ice Lake is manufactured with the bug as initial tape out of that was also back in June. Actual manufacture doesn't go into full swing till later this year.

    24. Re:Same syndrome as VW by strikethree · · Score: 1

      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?

      I am thinking that the engineers probably pointed out to management that skipping the ring check showed higher performance than performing the check but could be a security issue if timings were "just right". Management likely thought, "these CPUs are doing billions of things each second so there is a better chance of winning the lottery than being able to get at privileged data in the cache. Ship with higher performance."

      Odds for winning some lotteries is about 500 million to 1. Well, for an object doing billions of things a second, hitting a 1 in 500 million will not actually take all that long... and now, here we are.

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
    25. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      Greetings test subject, Cave Johnson here. Got some exciting news for you all! We've discovered a revolutionary new process to speed up our CPUs and push them past the competition! All it requires is removing every single security check that helps prevent unwanted outside software from reading and/or rewriting the source code located in the kernel
      I know, it's brilliant right? My idea personally. Now, you're probably wondering "isnt that extremely unsafe? What if word got out that this vulnerability existed"? Well, I say phooey to them. By the time it gets discovered, we'll already have secured 90% of marketshare. What are they gonna do, protest? Hah, not likely.
      Now, my engineers tell me this could lead to massive lawsuits and possibly all of aperture going bankrupt, so I fired them and hired some diversity hires for those sweet tax deductions. so as far as I'm concerned, there's no need for alarm for worry. The bug won't even be found for 15 years, and by then we'll all probably be dead. So don't sweat it.
      Cave Johnson here. We're done.

    26. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      There are two big differences though:
      - VW admitted and fixed the issue (at great cost). Intel admits the issue, but won't accept the consequences.
      - After VW admitted, it turned out that most other car makers were doing the same. So far, this issue seems limited to Intel and a few ARM chips.

    27. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      The emissions cheats in VW and other cars also had nothing to do with performance (and everything with cost), so the analogy fails even if Intel chose their design for performance reasons.

    28. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      It's much worse. VW admitted it when senior management found out and immediately started working on an actual solution, at great cost, despite the fact that customers were never in any way disadvantaged by the issue. They also sacked everyone who was involved and the people who were responsible and should have prevented this. Intel, on the other hand, has continuously downplayed the issue and they have already announced that they are not going to replace the defective CPUs that Intel knowingly sold, instead requiring them to use workarounds that severely affect performance without compensation.

      But then, Intel will probably get away with it, since they are American after all.

    29. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      The problem with this comparison with VW's emission hack is that Intel isn't guilty of falsifying the results of some government mandated test.

      To be fair, neither is VW.

      They just released a product with a security flaw, which was only recently discovered.

      By others, not by Intel. Intel has probably known about this for years.

    30. Re:Same syndrome as VW by Archtech · · Score: 1

      Are you mental?

      Like all other human beings, I am partly mental and partly physical. Why do you ask?

      there's software workarounds so there's no case at all to replace defective chips.

      The "software workarounds" are by no means comprehensive. They may well leave residual vulnerabilities, some of which cannot be dealt with by software patches.

      the performance hit will drive an increase in sales as datacentres make up the shortfall.

      This is the remark that really makes me believe you must work for Intel, hold Intel stock, or both.

      Intel has committed an incredibly serious blunder in its core expertise - chip design - and sold chips with that fault for maybe 20 years. The total harm to Intel customers and all the others downstream must run into tens of billions, maybe more.

      And you think that is all right ***because Intel will get yet more profits from selling yet more chips to compensate for its previous false promises?***

      --
      I am sure that there are many other solipsists out there.
    31. Re:Same syndrome as VW by Archtech · · Score: 1

      If they did not know it was a security risk, they should have known. This is their core expertise: designing processor chips.

      Modern corporations are past masters at hiding incriminating evidence, so I don't expect to see any public proof. At the very least the decisions made were grossly irresponsible.

      --
      I am sure that there are many other solipsists out there.
    32. Re:Same syndrome as VW by Archtech · · Score: 1

      Exactly!

      --
      I am sure that there are many other solipsists out there.
    33. Re:Same syndrome as VW by Archtech · · Score: 1

      you forgot to change accounts before replying to yourself

      Why would I do that? You musn't judge others by yourself - AC.

      --
      I am sure that there are many other solipsists out there.
    34. Re:Same syndrome as VW by Archtech · · Score: 1

      Good reasons to avoid a monoculture in such a vital industry, no?

      --
      I am sure that there are many other solipsists out there.
    35. Re:Same syndrome as VW by Archtech · · Score: 1

      ...have you never heard of erratas?

      "Errata". The singular is "erratum".

      --
      I am sure that there are many other solipsists out there.
    36. Re:Same syndrome as VW by Archtech · · Score: 1

      The VW fraud featured software routines that detected when an emissions test was being done. The software then switched the engine to a special mode that minimised emissions, at the cost of greatly reducing fuel economy.

      When the cars were driven on the road, in normal conditions, the emission-minimising feature was switched off - thus enabling the cars to deliver something close to their advertised fuel economy.

      Thus the company was able to advertise the cars as both meeting government emissions standards AND achieving good fuel economy. Whereas the reality was that they could do one thing OR the other, but not both at the same time.

      --
      I am sure that there are many other solipsists out there.
    37. Re:Same syndrome as VW by Archtech · · Score: 1

      Moreover, by refusing to compensate customers Intel has implicitly admitted that the costs of its mistake were greater than those of VW's. Yet it refuses to pay compensation or replace the chips. In other words, it is dumping the huge costs of its mistake on its customers, and telling them they can like it or do the other thing.

      --
      I am sure that there are many other solipsists out there.
    38. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      The VW fraud featured software routines that detected when an emissions test was being done. The software then switched the engine to a special mode that minimised emissions, at the cost of greatly reducing fuel economy.

      Not really. The difference is a few percent at worst. The real problem is that increasing EGR rates (like they did in test conditions) increases soot formation and pollutes the engine. It also increases the demands on the EGR valve. Both cause increased wear, reduced reliability and more under-warranty repairs. It's the same reason why everyone else was (and to some extent, still is), cheating diesel emissions.

      When the cars were driven on the road, in normal conditions, the emission-minimising feature was switched off - thus enabling the cars to deliver something close to their advertised fuel economy.

      Wrong again. The advertised fuel economy is measured under test conditions. Driving on the road (with lower EGR rates) leads to slightly higher fuel economy. This form of cheating exists solely to allow a car to pass NOx emission limits without the downsides of the cheapest way of achieving them. It doesn't help advertised fuel economy. To achieve a high official fuel economy (and thus low CO2) rating, a vast array of other tricks are used, but this one is actually counterproductive.

    39. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      So if VW got slapped 14.5 billion or more (i've lost count) AND their execs are being jailed.... Intel? Ah, American old school tie club, so NOTHING will happen.
      Me, I want Mr CEO to forfeit his big share-sales "bonus" AND I want a tech to arrive at my door to replace ALL my CPU chips - screw their cost. (I am not in the US, but so what - replace your %^%& faulty chip, you, you &*&%).

    40. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      There is no software fix possible that doesn't seriously reduce performance.

    41. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      There is no difference in intent. Both were conscious decisions by people who should have known better.

      There is one difference, though: Intel is American and it will therefore get away with it.

    42. Re:Same syndrome as VW by Anonymous Coward · · Score: 0

      Ford, General Motors and Fiat Chrysler also got away with emissions cheating without paying a cent (so far). It pays to be American and to have financed the right people's campaigns.

  4. Not surprising at all under the circumstances by Baron_Yam · · Score: 3, Interesting

    Seeing as replacing every Intel chip sold in the last decade would break the company overnight AND the problem can be patched (with an uncertain performance hit that may negligibly low in most scenarios, but could be ridiculously high in a few), I'm not in the least bit surprised by this.

    They're going to have to either kick it up a notch in the next product cycle OR find and release similar vulnerabilities in the competition's product lines or they're going to lose a bit of market share over this, though.

    I'd be shocked if they lost a huge portion of the market. There are a lot of PHBs out there who think Intel is the only option.

    1. Re:Not surprising at all under the circumstances by StatFiend · · Score: 1

      They're going to have to either kick it up a notch in the next product cycle OR find and release similar vulnerabilities in the competition's product lines ...

      The previous Slashdot article suggests Intel's spin-doctors are already doing just that.

    2. Re:Not surprising at all under the circumstances by eclectro · · Score: 2

      The fact is they could replace older chips a lot less expensively than people think. One reason if they use modern manufacturing to produce older chips the yield would be nearly 100%.

      --
      Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
    3. Re:Not surprising at all under the circumstances by admin7087 · · Score: 1

      The problem is that you cannot replace that many chips world-wide that easily. Manufacturing would be the least of their problems.

    4. Re:Not surprising at all under the circumstances by phantomfive · · Score: 1

      I'd be shocked if they lost a huge portion of the market. There are a lot of PHBs out there who think Intel is the only option.

      In addition, they probably are the only ones who can handle the volume for all the CPU manufacturers.

      --
      "First they came for the slanderers and i said nothing."
    5. Re:Not surprising at all under the circumstances by Anonymous Coward · · Score: 0

      replacing every Intel chip sold in the last decade would break the company overnight

      a) Can they patch it even if they wanted to? Right now their fabs are churning out Coffee Lake and Kaby Lake CPUs. How exactly will they refit their fabs to manufacture old, obsolete CPUs like Skylake, Broadwell Sandy Bridge?

      b) If Intel does not compensate users for the slow (5-30%) slowdown, then Intel profits from creating a buggy CPU, because many gamers and performance sensitive users will want to upgrade their CPUs so it will have the same speed as before the patch. And this is unfair to users that a company profits from creating a bad product.

    6. Re:Not surprising at all under the circumstances by Anonymous Coward · · Score: 0

      At least my Windows 98SE PC is safe.

    7. Re:Not surprising at all under the circumstances by Anonymous Coward · · Score: 0

      Those PHBs will quickly change their mind when customer retention is zero because your website doesn't work due to being hosted on a corrupted platform.

    8. Re: Not surprising at all under the circumstances by Anonymous Coward · · Score: 0

      How many years do you think it would take to replace 22 years of production?

      Why would you spend those years producing old chips few people want instead of modern chips?

      In addition, the old manufacturing processes donâ(TM)t exist anymore.

      How many chip designs were done in the past 22 years? Say itâ(TM)s at least 22 (new product every year). How are you going to find 22 design teams to un-archive those old designs (and the tools used) and design fixes for them? For process technologies that donâ(TM)t exist anymore (using equipment that was trashed log ago)?

      It would take decades â" and as economically useful as digging a whole and filling it up again.

    9. Re:Not surprising at all under the circumstances by Anne+Thwacks · · Score: 2
      The fact is that they could probably charge for the replacements if they enhance the performance of the old system. I would be happy to pay $30 to replace my core2duos with a plug compatible something that offered twice the performance. Give the size of the market, that should be very profitable for Intel.

      "You MUST by my chip, it will cost you $30" is a business even Al Capone could be happy with.

      --
      Sent from my ASR33 using ASCII
  5. 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.

    1. Re:A recall is absurd. Software is a thing. by AmiMoJo · · Score: 2

      I'd like to see an option to return my CPUs for a free fix. For some people the performance loss is significant.

      It won't happen because they don't make CPUs for those old sockets any more, and they aren't going to give me a free motherboard and RAM upgrade.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    2. Re:A recall is absurd. Software is a thing. by jittles · · Score: 1

      I'd like to see an option to return my CPUs for a free fix. For some people the performance loss is significant.

      It won't happen because they don't make CPUs for those old sockets any more, and they aren't going to give me a free motherboard and RAM upgrade.

      Are you claiming a real significant performance loss, and not a theoretical one? What workload are we referring to here? I think others would like to reproduce your results.

    3. Re:A recall is absurd. Software is a thing. by Anubis+IV · · Score: 1

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

      Issuing a recall doesn't mean that you'll successfully buyback every item that was sold. There may not even be a buyback program. And how quickly you've forgotten that society has dealt with far larger recalls, even in just the last year, in fact.

      Take VW's emissions scandal, for instance, which affected over 11 million vehicles. They were forced to recall vehicles spanning nearly a decade after they advertised performance numbers that were only achievable thanks to their use of a "cheat mode" that cut necessary corners. Fixes were possible, but they either cost VW money or resulted in worse performance. Many vehicles were "fixed" via software updates that were administered via the recall program—oftentimes resulting in worse performance—with many of those buyers receiving compensation for the difference in value between what was advertised and what they actually received.

      Likewise, Intel could be forced to recall chips spanning the last decade or more after they advertised performance numbers that may have only been achievable thanks to a design that bypassed necessary security checks at the time they were needed. Fixes are (in some cases) possible, but they they either cost Intel money or result in worse performance. Many chips can be "fixed" via software updates—resulting in worse performance for some/all use cases—and it stands to reason that affected buyers are entitled to receive compensation for the difference in value between what was advertised and what they actually received.

      Things are still shaking out, so we don't know how bad the performance hit will be. If it ends up being 0% for everyone, then all is well and Intel shouldn't be forced to pay. Unfortunately, there are some workflows (e.g. servers running VPSes) that so far as I know are still expected to see significant performance hits. If that ends up being the case, it's perfectly reasonable to demand that Intel issue a recall in which they either buyback those chips from the affected buyers or else provide compensation for the loss of performance that those buyers were promised (in much the same way that Sony was forced to pay PS3 users/buyback PS3s from users affected by the removal of Other OS).

    4. Re:A recall is absurd. Software is a thing. by Anonymous Coward · · Score: 0

      "and they aren't going to give me a free motherboard and RAM upgrade."

      And even if they did many software makers have rigged their software to be hardware specific, so you are forced to buy their new products each time you change PCs.

    5. Re:A recall is absurd. Software is a thing. by mlw4428 · · Score: 2

      Right, because FOSS has never had 20 year old bugs/security flaws. You cannot just implicitly trust ANY software unless YOU validate it. The problem is that 99.999999% of the population has no idea how to analyze software for security flaws. You either have to inherently distrust everything and base your technology around the concepts of lack of trust (such as the devs of Qubes do) or you accept the risk.

      Having the source code doesn't make an application anymore trustworthy from a security standpoint, unless you can use that source code to prove the software is secure. 99.999999% of FOSS doesn't do that.

    6. Re: A recall is absurd. Software is a thing. by Anonymous Coward · · Score: 0

      Yawn

    7. Re:A recall is absurd. Software is a thing. by Anonymous Coward · · Score: 0

      Doesn't matter. A product was purchased that was sold as being able to do x. That product can't do x. Therefore x is unfit for purpose.

    8. Re:A recall is absurd. Software is a thing. by erapert · · Score: 1

      Right, because FOSS has never had 20 year old bugs/security flaws.

      The AC didn't say that.

      You cannot just implicitly trust ANY software unless YOU validate it.

      For varying values of "implicitly trust"...

      The problem is that 99.999999% of the population has no idea how to analyze software for security flaws.

      From the AC that you attacked:

      ... 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.

      You either have to inherently distrust everything and base your technology around the concepts of lack of trust (such as the devs of Qubes do) or you accept the risk.

      That's true. But here you're kind of just agreeing with the AC.

      Having the source code doesn't make an application anymore trustworthy from a security standpoint, unless you can use that source code to prove the software is secure.

      But... this statement is self defeating! In the first half you say the source code doesn't help security but then in the next breath you say it could if it could be inspected... but that's what it means to have the source code: you can inspect it! Do you even hear yourself?!

      99.999999% of FOSS doesn't do that.

      That's what FOSS means: Free and Open Source Software. It means you can just read the code.

      Holy moley! Are you low on sleep or are you illiterate or both?

    9. Re:A recall is absurd. Software is a thing. by mlw4428 · · Score: 1

      > Holy moley! Are you low on sleep or are you illiterate or both?

      Take your own advice, chief: https://yourlogicalfallacyis.c...

      > ... 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.

      I wasn't going to go into the whole concept of "if you're good at something, never do it for free." There's no financial incentive to just go out and analyze FOSS out of the kindness of one's heart.

      > But... this statement is self defeating! In the first half you say the source code doesn't help security but then in the next breath you say it could if it could be inspected... but that's what it means to have the source code: you can inspect it! Do you even hear yourself?!

      What's being said - clearly you have problems with basic reading comprehension - is that FOSS isn't inherently better. Why? Because while you could inspect the source, the reality is that it's just not being done. Hell back in Feb Linux just closed an 11 year old security flaw. It took 11 years. That was only a few months after CVE-2016-5195 which was present for 9 years itself. The argument I'm making is that FOSS isn't inherently more security because the source code is visible BECAUSE there's not enough seriously investment in security-minded code review. Holy moley - are you stupid or something? None of this is hard to understand and you shouldn't have to be told it.

    10. Re:A recall is absurd. Software is a thing. by Solandri · · Score: 2

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

      A recall actually wouldn't be that expensive for Intel. Most CPUs and SoCs with the same die size as Intel's CPUs sell for only around $20. The $100 to several $1000 Intel is able to command for their CPUs is due to marketing and them being top dog. The material cost of the Intel* CPUs themselves is only a tiny fraction of their retail price. (Which raises the possibility of Intel doing a recall, taking a charge for it on their books based on the retail price, and getting a tax deduction for the "loss" which exceeds the manufacturing cost of the recall.)

      The bigger expense would be in the time to manufacture the CPUs (it would tie up their fabs for years) and the labor of actually replacing them. Desktops are pretty easy, but laptops with soldered BGA CPUs would be difficult to impossible. Another problem is that there simply is no performance-equivalent replacement for the highest-end CPUs. Any fix severely curtails performance, so a fixed CPU which has the same performance as a high-end pre-fix CPU may not exist for for several more years.

      * (We're pretty much only talking about Meltdown and Intel. From what I've been reading, the fixes for the other bugs affecting non-Intel CPUs result in minor to negligible performance hits. Which also makes me think I haven't been giving AMD the respect they deserve. I'd assumed they hadn't been able to match Intel's performance because they simply weren't as good at designing processors. Now it appears a large part of the reason was because they refused to follow Intel in doing something that compromised security to generate more performance.)

    11. Re:A recall is absurd. Software is a thing. by Anonymous Coward · · Score: 0

      Right, because FOSS has never had 20 year old bugs/security flaws. You cannot just implicitly trust ANY software unless YOU validate it.

      That's not the point. The point is that when you find a 20-year-old security flaw you have more options than hoping the proprietary company issues a fix or abandoning the software.

    12. Re:A recall is absurd. Software is a thing. by Anonymous Coward · · Score: 0

      On the bright side, one modern CPU could replace dozens of older CPUs. They can just give a batch of CPUs to a cloud provider and let the class action victims each obtain an appropriately sized VM after they mail in their old physical chip to obtain an appropriately sized virtual CPU license file.

  6. 70% Speed Reduction and No Rebate? by NicknameUnavailable · · Score: 1

    Yep, that sounds like Intel (at least after you add in the fact they're trying to spin it as a ~30% speed reduction, which would still amount to about $210 per processor to make for a fair rebate.)

    1. Re:70% Speed Reduction and No Rebate? by Megol · · Score: 2

      70%?

      What's with the obviously crazy people posting about this? Not only here but elsewhere including "articles" (read: crap) claiming the sky is falling and processors as we know them aren't possible anymore...

      Intel have a bug that leads to a potential security breach in certain systems under certain circumstances. Yes that's really really bad for some systems including cloud computing farms. It is bad as it opens up other systems for security breaches. But it isn't the end of the world.

      30% impact is for some kind of software and most software isn't impacted as much. Software doing heavy computation will have little performance impact.

    2. Re:70% Speed Reduction and No Rebate? by AvitarX · · Score: 1

      The specific case of du -s with a non PCID processor is close to a 79% reduction.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    3. Re:70% Speed Reduction and No Rebate? by Anonymous Coward · · Score: 0

      I've heard 5%-50%, depending on the load and type. Where I think you'll see the most bitching is cloud providers, because they ride the red line as a method of monetization, and while I'm sure they have extra capacity they can bring online, it's probably nowhere near 30%.

    4. Re:70% Speed Reduction and No Rebate? by NicknameUnavailable · · Score: 1

      Found the Intel PR shill. Protip: be less obvious next time.

  7. 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 Kierthos · · Score: 1

      That may be, but considering that the CEO sold millions in stock after learning of the problem, but before the hoi polloi were notified means that the SEC just might be crawling up his ass.

      --
      Mr. Hu is not a ninja.
    2. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      Extreme bs post by ac

    3. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 3, Funny

      Just like all the Equifax execs rotting in jail now...

    4. Re:Lawsuits on what grounds? by Pseudonym · · Score: 0

      I'm not sure you can even call this a "defect". The CPU is working as advertised, and it's not like it's insecure by design.

      If anybody sues Intel, they'll be suing Intel only for providing an optional feature that makes computations faster.

      Had this problem surfaced in the mid-90s, lots of OS researchers (yes, including Andrew Tanenbaum) would have argued that the CPU wasn't at fault, the operating system was.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    5. Re:Lawsuits on what grounds? by Smidge204 · · Score: 1

      It's arguable that the product isn't "defective." It's operating properly and as designed... It just happens that the design has a serious but unintended consequence.

      If someone uses a screwdriver to pry open a lock we don't say the screwdriver and/or lock is "defective." Inadequate maybe, but not defective.
      =Smidge=

    6. Re: Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      I want to rot in their jail too. Oh wait, I also want to be able to sleep at night.

    7. Re:Lawsuits on what grounds? by mysidia · · Score: 1

      The "scheduled sale" is a lie. No CEO dumps ALL of his stock.

      If they schedule the sale in advance and provide the required notice to shareholders, then they are legally able to sell as much stock as they want. If the CEO anticipates a drop or sees turmoil or sees themselves being fired or retiring, they may very well dump all their stock and get more back later through executive stock compensation.

    8. 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.

    9. Re:Lawsuits on what grounds? by 110010001000 · · Score: 5, Interesting

      Yes, it is insecure by design. What do you think the bug is? You cannot fix Meltdown because the flaw is in the hardware. You can only mitigate the effects.

    10. Re: Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      I doubt Intel knew about this for a long time. ME, sure, but this looks like an accepted design blunder industry wide.

      An inherent problem with tech is that it builds upon itself. In the name of efficiency, we often take existing tech paradigms for granted and never investigate or question them and build layers upon layers ontop of them.

      Once someone does dig around in the lower annals and discovers a flaw, security collapses, like this case.

    11. Re:Lawsuits on what grounds? by K.+S.+Kyosuke · · Score: 2

      This is a thousand times worse than the FDIV or f00f bugs.

      Not sure if it's strictly worse. At least you can do useful work on an airgapped machine. With the FDIV bug, not even a well-secured machine is useful in numerical computing scenarios. Unless you want to patch your compiler to emit a slower (on the average) routine for divisions, that is.

      --
      Ezekiel 23:20
    12. Re:Lawsuits on what grounds? by 110010001000 · · Score: 2

      No it isn't. One of the key features of the processor was memory access management. This is a HUGE bug.

    13. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      I'm not sure you can even call this a "defect". The CPU is working as advertised, and it's not like it's insecure by design.

      Except that the 386 would be considered secure for every modern OS implementation. The Pentium broke that to run faster.

      Had this problem surfaced in the mid-90s, lots of OS researchers (yes, including Andrew Tanenbaum) would have argued that the CPU wasn't at fault, the operating system was.

      But the OS would have to negate performance of the branch prediction strategy of the CPU. Sounds like covering up a design flaw of the CPU to me. I think OS designers are smarter than that.

      Here is an OS designer's response to the talk that this isn't a CPU design flaw:
      https://lkml.org/lkml/2018/1/3...

      At least AMD handled the situation correctly.

    14. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      You have absolutely no idea what you're talking about.

    15. 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
    16. Re:Lawsuits on what grounds? by Stormy+Dragon · · Score: 1

      Intel new about this defect in June. In the seven months since then, it's sold hundreds of millions of CPU it knew were defective, but chose not to disclose that fact. "Caveat Emptor" is not a defense to fraud.

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

      At LEAST until June. My guess is they have known about this for years, as the Meltdown bug is easy to understand once you have it explained to you. All those genius designers at Intel who designed the thing never thought about this? Baloney.

    18. Re:Lawsuits on what grounds? by thegreatbob · · Score: 1

      Couldn't really determine if I should downmod (i don't downmod for factual inaccuracies) this, so I reply instead. Trust me, my comment here is worse than any downmod. I feel the actual content has been addressed by other commentators, but I will give a car analogy. This is similar to buying a car, and then having to deactivate 1 or 2 cylinders on the engine, or locking out overdrive, to avoid some undesirable situation. You're calling 'firing on all cylinders' an optional feature; cars don't need an engine in the first place, of course.

      --
      There is no XUL, only WebExtensions...
    19. Re:Lawsuits on what grounds? by Anne+Thwacks · · Score: 1
      and it's not like it's insecure by design.

      Have you read a description of the hardware defects? It is exactly like it is insecure by bungling ineptitude and corner cutting

      If they advertised these defects, no one would have bought a single chip from them, ever.

      Its like selling buckets with hole in and saying "its OK if you carry them real fast".

      --
      Sent from my ASR33 using ASCII
    20. Re:Lawsuits on what grounds? by BradleyUffner · · Score: 1

      that is like your satnav giving you directions based on other cars movements.

      Like Waze does?

    21. Re:Lawsuits on what grounds? by thegarbz · · Score: 2

      You constantly use the word mitigate as if a patched workaround making the exploit unusable on the OS level isn't every bit the same thing as a hardware fix making the exploit unusable.

      And with first benchmarks out of the patched windows machines showing the performance impact for most normal loads lies somewhere between sweet and fuckall this really is every bit as overblown as many people are stating.

      Software has provided additional layers of protection over hardware since the DOS days. What makes this "mitigation" so scary to you that you're shorting Intel stock?

    22. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      Hmm, why does that comment remind me of the Sony PS3 firmware update removing the Other-OS feature? Not much came of that other than some whining, and the feature removal was intentional just to remove something they didn't like.

    23. Re:Lawsuits on what grounds? by thegarbz · · Score: 1

      The "scheduled sale" is a lie. No CEO dumps ALL of his stock.

      Sounds like you know a lot about "No CEOs". Good we got that sorted.

      The reality is that MOST CEOs dump their stock as soon as they can. The exception being those that started their own companies and still believe in endless growth potential. The vast majority of the CEOs in the world sit at the top of bluechip companies whose stocks are better liquidated and invested elsewhere.

      But then if it's a lie then it's a clear case of insider trading, and just like those other clear cases of insider trading that you and many other armchair legal experts on Slashdot called out, each were investigated and resulted in ... standard practice for scheduled stock sales.

    24. Re:Lawsuits on what grounds? by stevelinton · · Score: 1, Interesting

      No it isn't. One of the key features of the processor was memory access management. This is a HUGE bug.

      It's a bit subtle. The architectural requirements of the memory access management are entirely being met. The values in every register (etc) are exactly what they should be according to the ISA, The bugs work by causing a change to what data is cached, based on memory values they cannot actually access and then measuring load times for the data to see what is in the cache. There is, I suspect nothing in the ISA specification which says that this shouldn't happen.

      It also seems that there are genuine software solutions to most of this (modifiying the programs/OS holding the secure data so that it cannot be read this way), in which case they probably have an argument that software should have been written that way in the first place.

    25. Re: Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      It has a design defect. Those are very real in any QMS and in any hardware (e.g. Pipelines, ships, airplanes, rockets). Stop thinking like a software developer.

    26. Re:Lawsuits on what grounds? by 110010001000 · · Score: 1

      WRONG. What CEO dumps his stock to the MINIMUM level required in a single year? None. Quote:

      "In all the years I've been at this and of all the companies I've covered, I can't recall another single massive sale on this scale," Stacy Rasgon, an Intel analyst at Sanford Bernstein.

    27. Re:Lawsuits on what grounds? by gwjgwj · · Score: 1

      The branch prediction trains on other people's threads: that is like your satnav giving you directions based on other cars movements.

      Well, it does, e.g. when it directs you around the traffic jam.

    28. Re:Lawsuits on what grounds? by NicknameUnavailable · · Score: 1

      The "scheduled sale" is a lie. No CEO dumps ALL of his stock.

      If he puts an a limit order that's totally a scheduled sale, those things can take days to complete.

    29. Re: Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      It's more like them leaving otherOS and removing the ability to play videos. Including in game videos.

    30. Re:Lawsuits on what grounds? by 110010001000 · · Score: 0

      Quote: "In all the years I've been at this and of all the companies I've covered, I can't recall another single massive sale on this scale," Stacy Rasgon, an Intel analyst at Sanford Bernstein. What does a limit order have to do with anything?

    31. Re:Lawsuits on what grounds? by Ash-Fox · · Score: 1

      WRONG. What CEO dumps his stock to the MINIMUM level required in a single year? None.

      John R. O'Rourke III, Richard Smith, Travis Kalanick, Heather Bresch etc.

      Stacy Rasgon

      Never heard of her. I heard of the names I mentioned above though.

      --
      Change is certain; progress is not obligatory.
    32. 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.

    33. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      He knew months prior, he sold on this information. That we do know.

      What we don't know is if he knew long before that, given how much stock he's sold the past few years, even while Intel stock was up 25% over a year. Where there's smoke there's fire.

    34. Re:Lawsuits on what grounds? by 110010001000 · · Score: 0

      None of those CEOs have dumped all their stocks and options to the minimum level in a single year. NONE. Don't blame me because you are ignorant of finance.

    35. Re:Lawsuits on what grounds? by networkBoy · · Score: 1

      I hope they do. He's a disingenuous ass.

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
    36. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      Caveat Emptor?

      Christ, you are a toolbag.

    37. 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
    38. Re: Lawsuits on what grounds? by Type44Q · · Score: 0

      Really, just stop.

      I don't believe that's in the shill's job description...

    39. Re:Lawsuits on what grounds? by sexconker · · Score: 1

      You are a retard.

      If you sell something that is fundamentally broken, you must issue a refund or a working, equivalent replacement.
      If you knowingly sell something that is fundamentally broken, that's fraud.

    40. Re: Lawsuits on what grounds? by Type44Q · · Score: 0

      I was wondering why it suddenly reeked of unwashed bunghole and then I realized where you were speaking from.

    41. Re: Lawsuits on what grounds? by sexconker · · Score: 3, Insightful

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

    42. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      Travis Kalanick will be at the minimum shares when he sells. John sold all his shares technically, Richard Smith sold all the shares he was permitted. All within a single year, recently too!

    43. Re: Lawsuits on what grounds? by gnupun · · Score: 1

      People buy CPUs for their speed. The so-called fix for this massive bug eliminates a good chunk of the CPU speed that the consumer paid for. So the CPU is a lemon, and the consumer must be compensated somehow for using an inferior CPU.

    44. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      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.

      Yes indeed intel's engineers have been under continuous unrelenting schedule pressure since 1995, for more than two decades they haven't had time to do anything else!

      your argument is REALLY feeble

    45. Re:Lawsuits on what grounds? by BlueStrat · · Score: 2

      If you sell something that is fundamentally broken, you must issue a refund or a working, equivalent replacement.
      If you knowingly sell something that is fundamentally broken, that's fraud.

      No, sorry, that's not fraud at the levels of political donations that Intel makes.

      At those levels of political donations it then becomes "...an unfortunate design error for which Intel has already negotiated a full settlement with the government's lawyers that prevents any other parties filing civil actions against Intel, unfortunately, a gag clause in the settlement prevents details from being released."

      What, don't tell me you thought the US still operated based on the Rule of Law!?

      Strat

      --
      Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
    46. Re:Lawsuits on what grounds? by networkBoy · · Score: 1

      I can't speak back to 95, but I can speak back to 99.
      That is an accurate statement.
      There is *enormous* pressure, all schedules are don on a 50/90 interval:
      What is the 50% confidence schedule to complete, what is the 90%.
      In theory this means management can make an informed decision, in reality they aim for the 50 and then browbeat the engineering teams to meet that deadline.

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
    47. 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
    48. Re: Lawsuits on what grounds? by Lead+Butthead · · Score: 1

      I want to rot in their jail too. Oh wait, I also want to be able to sleep at night.

      Rest assured morally bankrupted people have no trouble sleeping at night.

      --
      ELOI, ELOI, LAMA SABACHTHANI!?
    49. Re:Lawsuits on what grounds? by networkBoy · · Score: 4, Interesting

      I read more, and it's actually a timing attack combined with a cache read.
      So...
      A little more problematic than I initially indicated because the cache does flush, but they're snagging it sooner. Linus has the right answer: Disable speculation when going into kernel/protected memory space. https://lkml.org/lkml/2018/1/3/797

      As to the block reuse issue, it's simply impossible for the system level design engineer to fully understand all those blocks, just like the the block level designers can't understand the entire system(s) that their block is used in. Intel's model is a library of known good blocks, system level designers then integrate these together.

      The issue is that all this is working "as designed" and there is a fundamental design issue (easy fix by Linus noted above). That this issue made it into a VHDL block that was vetted is *the* issue, but that this block was then re-used is expected. Since it never actually broke it never was refactored.

      I don't see a solution to the "teams in isolation" problem either. The CPUs and support circuitry (like chipset) are simply too damn complex for a human brain to hold an entire model of in any level of detail capable of being useful in a design context. In chipset I only had three areas that I focused on, there were many many others, some I had better awareness of than others. My blocks I knew inside and out, I knew how to tickle them, break them, etc. Blocks I interacted with I knew their internal block diagram, but not the low level functionality, and blocks orthogonal to my focus area really were just "block Foo connects to Bar and Baz, and I connect to Baz". So I need to understand Baz, but I'd just have to trust that the Baz - Foo interface was done correct.

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

      As an aside, I'm particularly curious when you retired and what CPUs you worked on :-)

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
    51. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      No matter what happens, the fault goes always to the highest person in power. Assuming the engineers are not skilled enough, it is the fault of the manager to hire and keep them (or not train them or to setup impossible schedules etc.). If the manager is not skilled enough to do this, it is the job of his/her manager to fire that manager and so on, all the way to the top. Even if someone break the law, it is the fault of the manager not to see this coming or not to setup proper safety protocols to prevent it.

      This it this way, if I would hire random people from the street and ask them to do brain surgery, would you blame them when people die or would you blame me?

    52. Re:Lawsuits on what grounds? by NicknameUnavailable · · Score: 1

      What does a limit order have to do with anything?

      You technically have to schedule them.

    53. Re:Lawsuits on what grounds? by thegarbz · · Score: 1

      RIGHT! Just because someone is as narrow sighted as you doesn't make it any less of common practice. Why do you think there's a requirement for CEOs to hold onto a minimum of stock for a defined period in the first place.

      I'll pause here for you to think about that ....

      Oh you got it yet? Yes that's right, because it's quite common not to hold onto stock, especially if stock is your primary method of payment.

    54. Re:Lawsuits on what grounds? by sexconker · · Score: 1

      The government can't strike a retroactive deal with Intel to prevent others from seeking restitution.
      At worst, they'd rig the class action suit. Any class member could then exclude themselves from the suit and sue on their own.

      And then there's Yurop to deal with. The EU loves bleeding corporations for money with all sorts of fines.

    55. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-heres-what-intel-apple-microsoft-others-are-doing-about-it/

      For the Spectre branch prediction attack, Intel is going to add new capabilities to its processors to alter the behavior of branch prediction. Interestingly, some existing processors that are already in customer systems are going to have these capabilities retrofitted via a microcode update. Future generation processors will also include the capabilities, with Intel promising a lower performance impact. There are three new capabilities in total: one to "restrict" certain kinds of branch prediction, one to prevent one HyperThread from influencing the branch predictor of the other HyperThread on the same core, and one to act as a kind of branch prediction "barrier" that prevents branches before the "barrier" from influencing branches after the barrier.

      These new restrictions will need to be supported and used by operating systems; they won't be available to individual applications. Some systems appear to already have the microcode update; everyone else will have to wait for their system vendors to get their act together.

      The ability to add this capability with a microcode update is interesting, and it suggests that the processors already had the ability to restrict or invalidate the branch predictor in some way—it was just never publicly documented or enabled. The capability likely exists for testing purposes.

    56. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      Disable speculation when going into kernel/protected memory space. https://lkml.org/lkml/2018/1/3/797 [lkml.org]

      ...on blacklisted CPUs, with an on/off option for people that really want to get their performance back.

      Which is pretty much what Linus has said ( "not all CPU's are crap" ... "workarounds should have a way to disable them" ).

    57. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      The OS mitigation
      1) Comes at a performance cost because it needs extra context switches, or disabling speculative execution entirely.
      2) Might have bugs in the OS that allow it to be bypassed in future.
      3) Doesn't help with alternative routes to trigger the same CPU bug that may be discovered in future.

    58. Re:Lawsuits on what grounds? by ravenshrike · · Score: 1

      God I wish I had mod points right now. That's some funny ass shit right there.

    59. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      Bait and switch is illegal. Intel sold a product that they claimed had a certain level of performance and it doesn't due to the patches needed to make it secure.

    60. Re:Lawsuits on what grounds? by ravenshrike · · Score: 1

      Consumer loads, not enterprise loads. However a great deal of Intel's current business is definitely server side. Which means that unless they fixed MELTDOWN in Ice Lake, and given that it was taped out(As in, sent to their fab facility) right around the time that they were informed of the bug by Google that's unlikely unless they pulled back on it, their sales of Ice Lake server chips will suffer in comparison.

    61. Re:Lawsuits on what grounds? by BlueStrat · · Score: 1

      The government can't strike a retroactive deal with Intel to prevent others from seeking restitution.

      Sure they can, they did it for telecoms when it came out about TLAs having locked 'secret' rooms at major telecom facilities tapping major internet backbone trunks.

      It's not a (D) or (R) issue in the main, as both sides seek to increase domestic surveillance, just differing in the details and who gets richest.

      Strat

      --
      Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
    62. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      Yeah, there's no way the original designers of this feature didn't know it was a potential security risk. They may have (incorrectly) convinced themselves it wasn't exploitable, but surely they knew they were playing with fire.

    63. Re:Lawsuits on what grounds? by strikethree · · Score: 2

      The CPUs and support circuitry (like chipset) are simply too damn complex for a human brain to hold an entire model of in any level of detail capable of being useful in a design context.

      I respectfully disagree.

      It is possible, but Intel is not likely to pay someone properly who can do that when what they "want" are really just easily replaceable assembly line engineers. To management, there is no reason to fully understand, it just needs to work.

      I get nausea and vertigo when I see large, fairly complex things that are vital but that nobody seems to have a full grasp of the whole system.

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
    64. Re:Lawsuits on what grounds? by Pseudonym · · Score: 1

      I have read a description. It sounds like many other exploits I've seen over the years which use an optimisation as an unanticipated attack vector, like DoS attacks which attack a hash table by crafting requests that fall into the same chain.

      It's not a bug in the sense that the system is doing what it was designed to do. Many eyes have looked at the spec and not noticed that it was exploitable. If you think it's so bungled, why hadn't one of the Linux or BSD devs discovered it before now?

      There is a large.class of engineering failures which some refer to as "BAD" (i.e. Based on Available Data).

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    65. Re:Lawsuits on what grounds? by Pseudonym · · Score: 1

      OK that is a fair comment. I was thinling of the variants that affected AMD and ARM when I said it didn't feel like a defect.

      You want a page that you can't access to look precisely like a hole. But you also want it to time precisely like a hole too.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    66. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      The EU loves bleeding corporations for money with all sorts of fines.

      That's the US. EU fines tend to be much more proportional to the offence.

    67. Re:Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      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.

      But suppose it is only vulnerable to attack by a newly developed tool. Say that tool is a very compact (say the size of a Bic lighter), very high temperature torch with no visible flame built from components which had been available for a long time but no one had previously figured out how to assemble them into such a tool -- let alone as a matter of public knowledge. In that case we wouldn't say the lock was defective. This case seems a little closer to my scenario than your scenario.

    68. Re: Lawsuits on what grounds? by Anonymous Coward · · Score: 0

      Indeed. I have not heard ANY reports of widespread insomnia from the White House or in the ranks of the majority party, who are complicit in this train wreck of an administration.

  8. Firmware fix? by Anonymous Coward · · Score: 0

    I thought the new microcode updates and bios updates that intel and oems are rolling out would be the fix. Not just a non fix mitigation. Is that wrong?

    1. Re:Firmware fix? by nctritech · · Score: 1

      Microcode can change a lot of things about a processor, but microcode generally works by "pulling a bunch of strings" in the CPU control unit in a particular order for each CPU instruction encountered. Those "strings" go to a bunch of complex hard-wired circuits that can never be changed. I seriously doubt that the characteristics of the CPU TLB can be changed with a simple microcode update.

    2. Re: Firmware fix? by Anonymous Coward · · Score: 0

      No, it's something that makes a software fix slightly less of a performance loss.

    3. Re:Firmware fix? by 110010001000 · · Score: 1

      Yes that is wrong. Intel is trying to fool you with terms like "microcode update" and "chip level fixes". There is no fix for Meltdown other than replacing your faulty Intel processor. NONE. If you don't believe me, ask the experts. You can only mitigate the issue.

    4. Re:Firmware fix? by Anne+Thwacks · · Score: 1
      I seriously doubt that the characteristics of the CPU TLB can be changed with a simple microcode update.

      probably not, but the ability to read the pipeline contents that was speculative and not used when not in kernel mode probably could be. That would be a significant improvement (like putting passwords on your baby monitor when having sex). Of course with the IoT's track record, that may not be possible either.

      --
      Sent from my ASR33 using ASCII
    5. Re:Firmware fix? by stevelinton · · Score: 1

      I'm not sure what you regard as the difference between a fix and a mitigation. If intel changed the processor so that no memory accesses were launched until the CPU knew for sure if the memory management was going to permit it execute them, they would be slower for legitimate workloads because more time would be spent waiting for data from memory after the accesses were launched later. Is that a fix or a mitigation? If you think that i a mitigation, then no fix may be possible at all. If you think it's a fix then why is swapping in a OS kernel that avoid sthe problem equally well with the same performance cost not a fix?

    6. Re:Firmware fix? by Anonymous Coward · · Score: 0

      The smallest fix for Meltdown in microcode is probably no fetches into main memory for speculative execution, which shouldn't cost too much (you're already blocking the bus on the non-speculative main memory fetch for most of the time).

      The smallest fix for Spectre is no fetches into main memory for speculative execution, which shouldn't cost too much (you're already blocking the bus on the non-speculative main memory fetch for most of the time).

      Yes, those two statements are almost identical.

    7. Re:Firmware fix? by Anonymous Coward · · Score: 0

      If intel changed the processor so that no memory accesses were launched until the CPU knew for sure if the memory management was going to permit it execute them, they would be slower for legitimate workloads because more time would be spent waiting for data from memory after the accesses were launched later. Is that a fix or a mitigation? [...] If you think it's a fix then why is swapping in a OS kernel that avoid sthe problem equally well with the same performance cost not a fix?

      I am not intimately familiar with all the details of Meltdown, but a hardware fix would simply perform access checks before speculatively executing an instruction. It wouldn't require flushing the TLB. A software fix, i.e. mapping in and unmapping the kernel, will flush the TLB. So you have that as an extra performance hit. To look at it another way, how would the performance of Intel cpus with OS patches for Meltdown compare to AMD cpus, which don't seem to need the OS to be patched? There may be other contributing factors to any difference observed, but it would be interesting to check.

  9. FUD. CEO sold half of his stock by Anonymous Coward · · Score: 1

    That's a lot, but it's not all.

    1. Re: FUD. CEO sold half of his stock by Anonymous Coward · · Score: 0

      He sold all the stock he was allowed to sell by the board.

    2. Re:FUD. CEO sold half of his stock by Anonymous Coward · · Score: 0

      He sold all but the shares that he was required by contract to keep. So you're right, it wasn't all of his shares, but he dumped all the shares he could.

    3. Re:FUD. CEO sold half of his stock by sexconker · · Score: 2

      I'd say he dumped all of his shares. The remaining shares are tied to the CEO position, which he currently fills. Those shares aren't his until he leaves the position or the legal requirement to sit on them and do nothing with them is removed.

  10. HW fix? When? by Anonymous Coward · · Score: 0

    Wonder if they will do an out of band silicon rev to fix this in current production processors. That would be a big financial hit for them. My guess is that they'll roll it into a their standard rev schedule. Since they've known about this for many months, maybe we'll see something soon. I was just about to start on a new build but that's now on hold. Wait and see I guess.

    1. Re:HW fix? When? by Anne+Thwacks · · Score: 1
      Wonder if they will do an out of band silicon rev to fix this in current production processors. That would be a big financial hit for them.

      If they DON'T fix it, then they may be seriously short of future customers. Now THAT would be a serious financial hit!

      --
      Sent from my ASR33 using ASCII
  11. 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/
    1. Re:This doesn't surprise by squiggleslash · · Score: 2

      i7 to i5 isn't really the right comparison. It's more like switching from a 7800rpm to a 5200rpm disk drive. I/O is going to be impacted. AI, physics, and graphics not at all.

      --
      You are not alone. This is not normal. None of this is normal.
    2. Re:This doesn't surprise by Anonymous Coward · · Score: 0

      This won't affect i7 processors for shit.

    3. Re:This doesn't surprise by edtice1559 · · Score: 1

      For a gaming machine, it's not clear that you even need to accept the update. Although this defect is ugly, in order to exploit it, you have to get a malicious program onto the machine initially. For a single-user system, such malware probably doesn't gain anything extra from this. The real impact will be to shared server machines. I'm not saying that this isn't ugly. It's problematic for any system that needs to ensure confidentiality as the patch will have to be applied and the performance hit taken. For gaming machines the increased risk from leaving this unpatched is almost zero.

    4. Re:This doesn't surprise by Anonymous Coward · · Score: 0

      Strange - Isn't graphics I/O as well? (CUDA, sending code to run on cards, getting results, trusting said cards and code, etc, etc, etc)

      Oh, wait, GPUs are a CPU as well...

    5. Re:This doesn't surprise by squiggleslash · · Score: 2

      Set-up requires kernel intervention, but you typically do that at the beginning and then everything else bypasses the kernel so while it's I/O, it's I/O that's not kernel bound.

      This is distinct from, say, reading files, where every block of data you read needs kernel intervention.

      --
      You are not alone. This is not normal. None of this is normal.
    6. Re:This doesn't surprise by Anne+Thwacks · · Score: 1
      Unless used as database servers, in which case, you are stuffed!

      But you use Oracle Sparc64 for all your database work, don't you?

      --
      Sent from my ASR33 using ASCII
    7. Re:This doesn't surprise by AmiMoJo · · Score: 1

      Cloud and VPS services are going to be hammered by this. It's a critical flaw for them and their systems do a massive amount of calling and switching in and out of the hypervisor and every running OS kernel.

      Imagine your service suddenly and permanently losses 30% of its capacity. Hundreds of millions of Euros of computing power wiped out. Your customers are pissed because their bills are going up as their apps suddenly need more CPU cycles...

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    8. 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.

    9. Re: This doesn't surprise by Anonymous Coward · · Score: 1

      Unless that single user machine runs a web browser. Exploit is out with five lines of Javascript. It's also how the iPhone was cracked.

    10. Re:This doesn't surprise by Anonymous Coward · · Score: 0

      Every Intel user will be effected. Anyone saying otherwise is ignorant or a liar. The only valid question is what the actual negative performance impact will be for all Intel users. The performance impact currently ranges from 5% to 60+%. The heavier the workload the more likely it is to become a performance issue.

    11. Re:This doesn't surprise by Anonymous Coward · · Score: 0

      And what "IO heavy strategy game" does he play? This sounds more like manufactured FUD than an actual example.

    12. Re:This doesn't surprise by Anonymous Coward · · Score: 0

      First of all, no CPU manufacturer makes any guarantees about specific performance levels of any given processor.

      Second, there are no solid numbers out there about the degree of performance degradation with any of the fixes that are being worked on. Any statements about the degree of performance degradation must be taken as pure speculation at this time, and as Intel notes, the amount of degradation will change over time as newer methods come along.

      My take is that your brother needs to chill out.

    13. Re:This doesn't surprise by Anonymous Coward · · Score: 0

      Yet again: "Move along, nothing to see here". What the fuck?

      So you think *all possible ways* of writing a Javascript exploit can be anticipated and patched in a few days, or indeed at all? You're either an idiot or yet another Intel shill.

      Let's just assume you're an idiot for the moment.

      There are an infinite number of ways to implement a given exploit in a general purpose programming language. There exist *no* methods for anticipating and blocking all these implementations without crippling the language. For non-idiots, it's effectively a variation on the halting problem**
      The browser makers will do their best to block the obvious ways. This will be a constant game of whack-a-mole with no real solution to *Intel's insecure and faulty chip design*

      **Halting problem: It's impossible to determine *in general* if a given piece of code will ever complete.
      Generalisation: It's impossible to determine *in general* what a given piece of code does (this follows automatically if you can't even tell if it will complete)
      Conclusion: Sufficiently complex and/or obfuscated Javascript for this exploit cannot be automatically detected and blocked

    14. Re: This doesn't surprise by Anonymous Coward · · Score: 0
      Firefox already pushed out an update. Fix the browsers and your desktop single user PC will be fine.

      Pull the other one, its got bells on. (Try to avoid naming a browser and claiming "you will be fine" in the same post in future).

    15. Re:This doesn't surprise by 110010001000 · · Score: 1

      You aren't too smart are you? A VM won't help. Do you even know what the flaw is? Malicious JS is everywhere. Advertisements, legitimate websites. You won't even know you are compromised.

    16. Re:This doesn't surprise by Anonymous Coward · · Score: 0

      > My brothers pissed because this is going to tank performance in the IO heavy strategy games he plays

      "Is going to".

      How is your genius of a brother substantiating that claim, exactly?

      Also: First-world problem.

    17. Re:This doesn't surprise by aliquis · · Score: 1

      Accept and accept.

      Of course you can avoid the update one way or the other. But you put yourself at risk.

      If you'll only run one game which you trust then maybe that's acceptable. However if you use your machine to surf the web aswell then I'd want to have it.

      Also even if you have the microcode update and Windows or Linux software update you can turn of the software solutions which I don't know how much of the hardware solutions that leave in place but yeah. It may be kinda possible to choose whatever you want to be protected or not and decide whatever you want the impact or not.

      Personally I can still return my stuff, maybe not the processor I don't know, and then I could wait for the next version of Zen. But the machine I would have left then is shit until then.

      I also get crashes daily for some reason which make that a more attactive options. Seem like it may be the graphics drivers which crash my machine but I don't know for sure.

  12. Well, that's the Broken Window fallacy. by Anonymous Coward · · Score: 0

    Yes, it might be a boon for some, but for society, it's clearly anti-profitable.

    All of the resources spent mitigating and monitoring these bugs could have been spent on other things, like bombing more nations or throwing more pot smokers into cages.

    1. Re:Well, that's the Broken Window fallacy. by Anonymous Coward · · Score: 0

      Microsoft has kept half of the tech industry employed for decades with buggy products that required massive support.

    2. Re: Well, that's the Broken Window fallacy. by Anonymous Coward · · Score: 0

      At least we flew those plane loads of cash Iran.

    3. Re:Well, that's the Broken Window fallacy. by Anne+Thwacks · · Score: 1
      All of the resources spent mitigating and monitoring these bugs could have been spent on other things, like bombing more nations or throwing more pot smokers into cages.

      Or employing CPU designers that know how to do their job.

      --
      Sent from my ASR33 using ASCII
  13. 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.
    1. Re:Sorry, but no, sorry. It's not "fixed" by Anonymous Coward · · Score: 0

      Recall to what? Seriously this affects a lot of CPU's, exactly what would a recall do? There is no fix as you say, then what would it be replaced with? Should someone with a Celeron get a Ryzan replacement? Or just a refund for the chip? Then what do you do? Would you expect a refund from Microsoft for Windows because you got malware? Don't see it happening, and all chips have flaws some fixed some not. Some affect performance, some don't. Not everything is perfect, and we have yet to see any proof of performance hits, or problems associated other then some who claim to look at Linux fixes that would appear to slow some processes. This may be limited to Linux and simply a rush to fix, or a result of how Linux handles predictive executions. At this point everything is speculative and worse case scenario sky is falling hype with no real proof. That won't ever hold up in a lawsuit.

    2. Re:Sorry, but no, sorry. It's not "fixed" by Anonymous Coward · · Score: 0

      A prorated rebate based on lost performance using a common ratings system for any chips sold in the last six months, a period during which Intel demonstrably knew of the flaw and continued to sell affected chips, would be a good start.

    3. Re:Sorry, but no, sorry. It's not "fixed" by Anonymous Coward · · Score: 0

      Good luck getting a microcode patch to a motherboard that is 10 years old (and that's not even very old since motherboard tech has changed so little in the last decade).

      What are those people suppose to do? Oh, I know your answer: Buy newer hardware! Right, spend money for no reason. Great answer.

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

      My money back, for example? I bought an Intel CPU for a specific purpose and instead of a competing CPU due to a superior performance, which is simply no longer existing after this "update". If this gets to stand, rest assured that we'll get to see a lot of CPUs in the future with microcode cutting corners to get a performance edge in the early release tests which suddenly go poof when (not if) the security and stability tests provide evidence that these corners cut make the CPU as stable and reliable as a pig on stilts. Then the microcode patch comes in and, surprise, surprise, your CPU suddenly performs like the prior generation CPUs.

      If you want that then yes, there is no good reason for a recall.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  14. Comment removed by account_deleted · · Score: 0

    Comment removed based on user account deletion

  15. Intel *will* settle at some point... by MetricT · · Score: 5, Interesting

    The bug primarily affects large cloud vendors like Google, Facebook (who have entire buildings filled with lawyers) and HPC clusters (many of which have law *schools*).

    Without the patch, the computers are vulnerable, and large data centers *must* upgrade given the size and value of the target they are. However, the loss in performance may be substantial. I help manage a ~2000 server HPC cluster. If the patch causes us to lose 5% of our performance, that's like throwing 100 computers away. Which is completely and utterly unacceptable, and we as well as others have the resources to make that crystal clear to Intel.

    1. Re:Intel *will* settle at some point... by Anonymous Coward · · Score: 0

      The part I don't understand is how Intel thinks they're going to get away with offering nothing but apologies and patches that entail a performance hit, when on the scale of an entire building full of servers it will cost companies real money if there is a performance hit.

    2. Re:Intel *will* settle at some point... by stevelinton · · Score: 1

      I suspect HPC will take little or no performance hit. The hit comes on workloads that do LOTS of system calls. HPC does hardly any.

    3. Re:Intel *will* settle at some point... by houghi · · Score: 1

      Google already stated that the loss im performance was minimal. In fact they said negligible impact on performance followed by a YMMV. That means it is nowhere near the 5%. Remember that is is google who might have a bit more than 2000 servers worldwide.

      So first measure how much impact it is. Could be that the typing you did was more expensive than the loss in performance over a year, Or perhaps 5% is way to low for your situation and it is more at 50%.

      --
      Don't fight for your country, if your country does not fight for you.
    4. Re:Intel *will* settle at some point... by Wrath0fb0b · · Score: 1

      Why in the world would you patch a HPC cluster? The security issue described is completely not applicable in this case -- these aren't processing TLS connections, dealing with sensitive data or whatnot. I used to do computational physics (albeit in a different decade/life) but I can't imagine what use I would have had snooping the entire memory of our cluster nodes. At worst, I guess I could game the quota to get free hours, but that's hardly the end of the world.

      The most it seems you should be upset at Intel for is a few days of support time to reconfigure the kernel builder to disable KPTI and be done with it.

    5. Re:Intel *will* settle at some point... by 110010001000 · · Score: 1

      WRONG. Google was talking about a different issue that solved their particular problem. They recompiled the binaries on their server farms to work around the issue. Hackers aren't going to do that. Their solution won't work for anyone else.

    6. Re:Intel *will* settle at some point... by Just+Some+Guy · · Score: 1

      If you own the cluster, do you actually need to apply the patch? It seems like your security exposure would be far small than, say, Amazon's multi-tenant hardware.

      --
      Dewey, what part of this looks like authorities should be involved?
    7. Re:Intel *will* settle at some point... by MetricT · · Score: 1

      There have been suggestions that pure compute jobs may indeed be relatively unaffected. But high-IO (GPFS, Luster, similar filesystems, as well as 100 Gb networking) may be seriously impacted.

    8. Re:Intel *will* settle at some point... by MetricT · · Score: 1

      > Why in the world would you patch a HPC cluster? The security issue described is completely not applicable in this case -- these aren't processing TLS connections, dealing with sensitive data or whatnot

      No offense, but you seriously *do not* have any idea what you're talking about. Our cluster is used by departments across the university, including some under HIPPA, ITAR, or similar regulations.

      And yes, a great many of our jobs are opening TLD connections and dealing with sensitive data.

      You're trying to extrapolate the entirety of HPC from your personal experience, and that's wrong.

    9. Re:Intel *will* settle at some point... by Anonymous Coward · · Score: 0

      This is ultimately good for the overall computer market, since AMD will start making inroads in the cloud with their new threadripper CPUs.

    10. Re:Intel *will* settle at some point... by Anonymous Coward · · Score: 0

      Why in the world would you patch a HPC cluster? The security issue described is completely not applicable in this case -- these aren't processing TLS connections, dealing with sensitive data or whatnot. I used to do computational physics (albeit in a different decade/life) but I can't imagine what use I would have had snooping the entire memory of our cluster nodes. At worst, I guess I could game the quota to get free hours, but that's hardly the end of the world.

      The most it seems you should be upset at Intel for is a few days of support time to reconfigure the kernel builder to disable KPTI and be done with it.

      People like you are the reason why HPC administrators don't trust their users. You really can't think what someone else might accomplish by compromising an HPC cluster? Lots of HPC clusters now work with HIPAA and other protected data. That alone could be worth tens of millions of dollars in fines and lawsuits to a university. What about people who like destroying things for fun?

    11. Re:Intel *will* settle at some point... by Anonymous Coward · · Score: 0

      And what about disgruntled employees who want to do some damage on their way out?

    12. Re:Intel *will* settle at some point... by Wrath0fb0b · · Score: 1

      I mean, I have a doctorate in computational physics. We had a half million dollar grant for our own HPC cluster. I had many thousands of hours of jobs run on other university systems. There's no need to suggest that I have no idea what I'm talking about. It's beyond rude.

      If I were still at my old job, I would without a doubt recommend disabling KPTI on our cluster.

      [ Amusingly enough, my current job is security engineering. ]

    13. Re:Intel *will* settle at some point... by MetricT · · Score: 1

      > I mean, I have a doctorate in computational physics. We had a half million dollar grant for our own HPC cluster. I had many thousands of hours of jobs run on other university systems

      And yet you're still wrong. Since you're throwing credentials around, I have two graduate degrees (theoretical physics and MBA), our cluster is about 10 times bigger judging by price, and I have 15 years experience here in the "real world", and another 5 years in grad school writing parallel Fortran code on a DEC Alpha cluster.

      Speaking as someone who handles security at our site, we are enabling KPTI on our compute clusters because they exist in a shared cluster, and we don't want our non-HIPPA/non-ITAR users to be able to snag credentials from HIPPA/ITAR users.

    14. Re:Intel *will* settle at some point... by MetricT · · Score: 1

      Yes, because we have users from multiple departments, including physics, economics/finance, medical, engineering. Some of those users are working on HIPPA or ITAR data, and we have to apply the patch to ensure that other users can't snoop anything that doesn't belong to them.

    15. Re:Intel *will* settle at some point... by Wrath0fb0b · · Score: 1

      Well, I never insulted your credentials or insinuated you had no experience in the matter, so it's a bit of a different story there.

      Anyway, substantively, if you really care so much about HIPPA users, partition them off so that they occupy a node exclusively with no other cluster jobs running concurrently with them. The unused partial nodes there seem like a much better tradeoff than a 10% penalty for all the regular HPC users (MD, CFD, QED, QCD, ....).

      This is probably true unless the number of confidential jobs approaches 20% or more of the total job-hours, at which point it's probably best to just create KPTI+ and KPTI- nodes and have the scheduler assign the confidential jobs only to the KPTI+ nodes. Anyway, the regular jobs can also run on the KPTI+ nodes at a modest penalty, so it's basically free performance.

      Just some thoughts. I haven't "done" HPC in a decade, but security engineering gives one a view for mitigating risks while still delivering the needful.

    16. Re:Intel *will* settle at some point... by Anonymous Coward · · Score: 0

      You know, that funny corner of HPC where you build a cluster and run a batch job scheduler but then let people login and timeshare the nodes too. In other words, one where you don't care about high performance at all.

      My knowledge of HPC centers is that they already know computers aren't that secure, and real sensitive processing is compartmentalized and always has been since Cray vector machines started giving way to networked clusters. You don't mix job loads from different confidential client pools without essentially decommissioning and recommissioning an HPC machine. In some cases that means scrubbing all the disks and resetting all the firmware, e.g. for financial/trade secret confidentiality that has a dollar value for risk mitigation. Truly sensitive stuff means you send the old parts to scrap and install new ones for the next iteration, since they always knew to be cautious about writable firmware hosting persistent malware infections.

  16. Intensive Intel research shows by nagora · · Score: 2
    that this is someone else's problem.

    Intel CEO Brian Krzanich said the new problems are much more easily fixed by other people who knew what they were doing. "After all," he continued, "do you want the idiots who did this to work on the fix? You're better off doing it yourself. I'll be at the beach if you need me."

    --
    "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
  17. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  18. You keep saying that, I don't think it's true. by Brannon · · Score: 3, Informative

    AFAIK the kernel software workaround (called KPTI in Linux) makes it impossible to exploit the Meltdown hole (i.e. variant #3 from Project Zero). There's some performance cost but Google has measured the cost as negligible on real workloads. I'm running with a similar patch in OS X and I can't tell any difference.

    It doesn't matter if the original bug is in the HW or not, so long as there is a workaround at some layer (firmware, kernel, etc.). You are beyond naive if you think this is the first time a HW bug has been masked by SW--it happens all the time. Usually the workaround is buried in a driver or firmware and you never hear about it.

    1. Re:You keep saying that, I don't think it's true. by Anonymous Coward · · Score: 0

      There are going to be a number of large customers that Intel is going to have to "make happy" behind the scenes. If this happens with enough large customers,.soon it becomes a house of cards that gets blown over with a breeze.

      Other posts from engineers describe meetings a number of years ago when they had to cut corners to make sales deadlines. Don't think that won't come out to court.

    2. Re:You keep saying that, I don't think it's true. by Anonymous Coward · · Score: 0

      but Google has measured the cost as negligible on Google's real workloads

      Fixed that for you. Some workloads are severely impacted and some aren't. Just because Google isn't severely impacted doesn't mean that others aren't.

    3. Re:You keep saying that, I don't think it's true. by Anonymous Coward · · Score: 0

      If you are referring to yesterday's story, that wasn't about KPTI but about a code change against one of the other variants that don't cross privilege boundaries. KPTI will definitely have a non-negligible performance impact. CPUs need caches in order to be fast, and KPTI invalidates all translation lookaside buffers (TLB) for kernel pages every time a process exits a system call and returns to userland.

    4. Re:You keep saying that, I don't think it's true. by ravenshrike · · Score: 1

      Retpoline is the only fix that has negligible performance impact on all workloads and only affects the other two variants of SPECTRE. KPTI has significant performance impact on virtualization and certain types of storage workloads, but not on consumer workloads. Moreover, Retpoline doesn't work on Skylake or later chips. Which means that in addition to the perf impact from fixing MELTDOWN, they get another performance impact from fixing the other two variants on those processors.

    5. Re:You keep saying that, I don't think it's true. by strikethree · · Score: 1

      AFAIK the kernel software workaround (called KPTI in Linux) makes it impossible to exploit the Meltdown hole (i.e. variant #3 from Project Zero). There's some performance cost but Google has measured the cost as negligible on real workloads.

      You do not understand what the "patch" does.

      Semi-technical answer:
      It clears the cache a lot.

      Caches started to be added to CPUs because primary RAM is magnitudes slower than CPU processing capabilities. It is rather like the difference between helping someone over the phone and giving them verbal instructions versus sitting down at the keyboard and doing it yourself.

      For end user workloads, this is not a huge deal most of the time because even the "talking over the phone" is MUCH faster than we perceive. That is why you are not noticing anything.

      However, databases and web servers and other I/O intensive apps will be severely affected. The 5% number is for a CPU that is not pegged doing useful work. Once you throw a serious load at it, the lack of caching is going to be absolute murder. Back of the envelope estimates are close to 40% performance hit. It could even be worse, we will have to see.

      But yeah, for end users that are not hardcore gamers, the patch is a non-issue. Some gamers will not even be affected because their games are GPU bound, not CPU bound.

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
    6. Re:You keep saying that, I don't think it's true. by Brannon · · Score: 1

      Why would it need to clear the cache? It should just need to purge the TLB on transitions from kernel -> user. I think maybe you don't understand what the patch does.

      I couldn't care less about gamers. Neither does the rest of the world. Grow up.

  19. You're not as influential as you think you are. by Anonymous Coward · · Score: 0

    You'll find that out on your own.

    1. Re:You're not as influential as you think you are. by ytene · · Score: 1

      MetricT's company might not be all that influential as a single company - we just don't know. But there is nothing to stop all the major cloud providers from agreeing to join forces in a class-action lawsuit against Intel - and they have the backing and clout to make sure they get it.

      The challenge for Intel here is that the harm is done. They need to repair both the reputational harm and the actual damage this incident has caused.

      It took Apple a couple of days to figure out the damage being done by the iPhone battery issue [they likely got data directly from their sales channel and saw an immediate decline in sales] but Intel face the same hurdle here. Remember, though, that Intel are shielded from immediate effects because they only sell to integrators and channel partners. It might take 3 months before they actually saw sales diminish.

      It won't lessen the impact when it comes.

      The best thing Intel can do right now is to prepare a recall or offer a trade-in and get ahead of the negative publicity. Only their greed and their hubris is stopping that.

    2. Re:You're not as influential as you think you are. by Anonymous Coward · · Score: 0

      I don't think they have a case - no CPU manufacturer guarantees performance levels in specific cases.

  20. Are Intel SGX enclaves snoopable too? by Anonymous Coward · · Score: 0

    Intel has a technology called SGX that purports to isolate data running within "secure enclaves" ... so can these vulnerabilities read into SGX-protected memory too?

  21. Recall will never happen by Anonymous Coward · · Score: 0

    People are dreaming that Intel will end up coughing up a settlement for what is a flaw found in hardware anymore then Microsoft would be liable for one found in Windows. No such thing as guaranteeing the hardware will never have a flaw. Also no proof what so ever Intel knew anything about this until last Summer when it was informed of the proof of concept. Personally, everything I have read seems to indicate this will be mitigated through patches and firmware updates and any risk left would be so limited in scope its not worth being concerned about. We have far more riskier stuff in the wild now that is much more effective. Nobody thinks any litigation will be able to prove any malice by Intel or any other chip maker.

    1. Re:Recall will never happen by 110010001000 · · Score: 1

      Nice try. Intel has done recalls for much less. There is no "firmware update" that will fix it. This is a huge flaw that cannot be fixed. But nice try at spinning it.

    2. Re:Recall will never happen by Anonymous Coward · · Score: 0

      "nice try at spinning it'!. Pretty rich coming from someone operating off of pure speculation. Nothing that you have been writing has any validation by anyone with any true knowledge and understanding in depth. Everything in the news so far is coming from people with far more interest in getting the scoop than in waiting for the truth.

  22. What about kicking Intel out for AMD! by Joe_Dragon · · Score: 1

    What about kicking Intel out for AMD!

  23. Time for AMD EPYC where are the 1P boards super mi by Joe_Dragon · · Score: 1

    Time for AMD EPYC where are the 1P boards super micro?

    H11SSL-i / H11SSL-C / H11SSL-NC does someone have an link to a store where I CAN BUY them??

  24. Someone make an amd ryzen board with ipmi! by Joe_Dragon · · Score: 1

    Someone make an amd ryzen board with ipmi! for systems that don't need an high end epyc system. Like xeon e3

  25. How does this affect me? by Anonymous Coward · · Score: 0

    I mean really. my processor works fine the way it is. Can I opt out of any 'fix'?
    The way I use my computer for gaming, etc. I don't see this bug as a problem for my situation.
    If the OS applies a 'patch' to my processor that kills performance, then I have an issue. I the patch is inside the OS itself and leaves the processor alone, then fine. But don't touch my silicon without my consent!

    1. Re:How does this affect me? by Anonymous Coward · · Score: 0

      Have you read none of the articles and references? The slowdown is very workload-dependent. IOW software-dependent. If the software rarely makes system calls (i.e. most games) then the slowdown will be minimal. If it makes a ton of them (i.e. databases) the slowdown is significant. For home users, even heavy gamers, it's unlikely to be very noticeable using recent CPUs (Intel apparently had a partial fix already in hardware of the last couple of generations, so the patch has hardware support and runs faster); but yes, there will be a slowdown however slight. For those of us with older CPUs, there will be more of a hit, but nowhere near what the datacenters are going to have. But to your main question: if you want to block the Windows Update that includes this, and you have the ability to, go ahead. Just don't complain when some hacker figures out a way to make trouble (or money) using it and your unpatched computer becomes part of the botnet or otherwise gets hosed.

  26. Doing it Right - Deploying a Patch by pubwvj · · Score: 1

    If there is no need for a physical recall and a simple software patch does the job then that is the right thing to do. It is better for Intel, better for customers, better for vendors, better for the economy and better for the Earth. A physical recall has very high costs for each of these groups. Yes, some people might like a 'shiny new computer' out of the deal but that is just greed. Unfortunately there will likely be some lawyers who will try and get rich on this with a big lawsuit. Shakespeare them. ("First thing we do is kill all the lawyers." -S)

    1. Re:Doing it Right - Deploying a Patch by 110010001000 · · Score: 1

      There is no "simple software patch" that will "do the job". That is the point. But nice try at the "save the Earth" spin.

    2. Re:Doing it Right - Deploying a Patch by pubwvj · · Score: 1

      Hmm... So you say there is no software patch yet people at Intel and other companies say they are releasing a software patch. I think I'm more incline to believe them than you.

  27. No. by Anonymous Coward · · Score: 0

    You can be sure that the next time his company buys some replacement computers, he's right their explaining to the boss that he needs to buy AMD instead.

    1. Re:No. by erapert · · Score: 1

      Until some similar bug crops up on AMD too.
      The proper approach to unreasonable people is to ignore them.

  28. Lots of hand-wringing & schadenfreude here by Brannon · · Score: 2

    This was not Intel knowingly cutting corners. The amount of verification that goes into building a CPU is mind-boggling. There are dozens of layers of constrained-random verification, formal verification, electrical verification, performance verification. The techniques used are decades beyond the types of QA testing that most people on this forum are familiar with.

    This is just not an attack-vector that computer architects are used to reasoning about. For the most part, the security isolation story is based on keeping architected state separate--caches are supposed to be architecturally invisible so you don't think of them as being an attack-vector. You certainly don't think of the measurable access latency through the cache hierarchy as being part of the attack surface; classically when we're reasoning about process isolation we aren't thinking about timing at all.

    The exploit here relies on measuring the latency to access some piece of data that you have permissions to, and using that to infer the value of a piece of data that you don't have permissions to--it turns out the two are connected due to the way exceptions are handled during speculative execution. It slipped through the cracks. Mistakes happen.

    You're well within your rights to complain about how Intel is reacting to the bug--but it is absurd to claim that they "knowlingly cut corners". I have no way of knowing, but my guess is that you churn out buggy Javascript for a living--which makes your 'holier than thou' attitude even more misplaced.

    1. Re:Lots of hand-wringing & schadenfreude here by lgw · · Score: 1

      This is just not an attack-vector that computer architects are used to reasoning about.

      That's security in a nutshell. But, really, CPU-behavior-related side-channel attacks are old hat. Any behavior in a core/thread that depends on the behavior of other cores/processes is the basis for some side-channel attack.

      The current mental model of isolation is clearly just the wrong one from a security perspective. Architects need a much broader view here.

      But who am I kidding, this is the company that added a whole extra OS worth of attack vector to their CPUs (a feature that very few customers were asking for, or even see positively).

      --
      Socialism: a lie told by totalitarians and believed by fools.
    2. Re:Lots of hand-wringing & schadenfreude here by ravenshrike · · Score: 1

      Yep, which is why MELTDOWN also affects AMD processors. Oh wait... they explicitly disallow this type of permission hopping. Why? For security reasons.

    3. Re:Lots of hand-wringing & schadenfreude here by nahpets77 · · Score: 1

      Please mod this up. I work as a CPU design verification engineer and the parent post describes most accurately what designing and verifying a part with millions (and billions) of transistors is all about. Hundreds of people are involved in the design and verification of these things; defects are bound to slip through.

    4. Re:Lots of hand-wringing & schadenfreude here by Archtech · · Score: 1

      Hundreds of people are involved in the design and verification of these things; defects are bound to slip through.

      If that is the case, then they should reduce the excessive complexity until skilled experts are able to avoid defects.

      Security is like virginity: indivisible. You can't be "just a little bit insecure". Corporations like Intel clearly and emphatically market their chips as incorporating security features; otherwise they wouldn't be able to sell any of them.

      The correct approach is to ensure security, and then, if desired and to the extent desired, optimise for performance within boundaries rigorously observed in order to preserve security. To optimise for performance without ensuring ironclad security is hopeless - and stupid. Note that the remedies for Meltdown will more than wipe out the performance gains obtained by the ill-advised speculative execution.

      --
      I am sure that there are many other solipsists out there.
  29. The I/O performance is still impacted by the CPU by rsilvergun · · Score: 1

    when you put it like that it makes it sound like the problem is his hard drive, which it's not. A faster drive wouldn't fix the performance issues either (e.g. it wouldn't make the CPU turns faster).

    --
    Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
  30. This doesn't compute. by Anonymous Coward · · Score: 0

    It will be cheaper to rearchitecture the hypervisor.* Plus as I've already pointed out the biggest cloud makers aren't like the rest of us. They have custom hardware and silicon done. Also the performance hit isn't an across the board thing because they have different servers for different tasks. e.g. database.

    *One of the selling points of virtual hardware.

  31. If you're on Win 10 you pretty much have to by rsilvergun · · Score: 1

    It's damn near impossible not to. He's on Win 7 though so he's OK. My Win 10 machines didn't let me say no. I suppose I could manually remove the patch but I'm 90% sure they're gonna try and install it again.

    --
    Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
  32. Boo hoo by Viol8 · · Score: 1

    Perhaps it might incentivise him to get out the basement and go get some exercise instead.

    1. Re:Boo hoo by Anonymous Coward · · Score: 0

      The 80's were a long time ago old man. Bullying nerds is no longer socially acceptable. They rule the world now. Today's gamer is tomorrow's (and often today's) "Bill Gates", to use a reference that is old enough for you to be familiar with.

    2. Re:Boo hoo by Viol8 · · Score: 1

      Yeah right. Todays gamer is tommorows fat cardiac arrest victim. The next Bill Gates is designing and writing the games, not sitting eating pizza playing them.

  33. Spectre vs Meltdown, you are picking nits: by DanDD · · Score: 3, Informative

    mysidia said "Non-Intel platforms are affected by the same form of problems" (emphasis mine). This doesn't seem like a lie: Understanding Meltdown & Spectre: What To Know About New Exploits That Affect Virtually All CPUs

    I'm not a CPU architect, and perhaps you are, which would explain why you seem to take the differentiation of these bugs and exploits so seriously. Or perhaps you are paid by AMD or an ARM vendor.

    Or maybe it's that your statement: "the world revolves around me" suggests that there might be other issues behind your comments

    --
    "Every time I see an adult on a bicycle, I no longer despair for the future of the human race." - H. G. Wells
    1. Re:Spectre vs Meltdown, you are picking nits: by 110010001000 · · Score: 1

      Meltdown is a much much bigger issue than Spectre is. Meltdown is an Intel only issue. I cannot make it more simpler. Please do some research before commenting. You don't need to be a CPU architect. The papers explain the problem very simply.

    2. Re:Spectre vs Meltdown, you are picking nits: by davros74 · · Score: 1

      Wrong. ARM has confirmed their Cortex A75 CPU is vulnerable to Meltdown (Variant 3). Please see their official statement here: https://developer.arm.com/supp...

    3. Re:Spectre vs Meltdown, you are picking nits: by Anonymous Coward · · Score: 0

      Spectre can be avoided in software without a performance impact. And it only affects code accessing userspace memory within the same process so the damage is limited, somewhat.

      Meltdown can also be avoided, but only with a 5-30% performance hit depending on workload because it involves increasing the number of context switches dramatically. And because it affects kernel memory you can break out into other programs and even other virtual machines, which means other companies in the cloud.

      So that's the difference - meltdown has worse damage potential and means your CPU is running up to 30% slower than before, and those clock cycles is directly translatable into money (either your CPU is now the speed of a cheaper one, or you need to buy 30% more servers).

      Also since they're still not actually making the processor check it has permission to access the memory during speculative execution I wouldn't be surprised if another pathway is found to trigger the same behaviour.

    4. Re:Spectre vs Meltdown, you are picking nits: by ravenshrike · · Score: 1

      Which is a bit like saying that both steel and paper can burn. True, but steel requires a temperature one hell of a lot higher than paper to do so.

  34. This doesn't SIMD. by Anonymous Coward · · Score: 0

    Only in the mathematical, logical, and I/O sense. Otherwise there are important differences, partially due to workload, and lineage.

    https://stackoverflow.com/questions/27333815/cpu-simd-vs-gpu-simd

  35. Question on Timing by ytene · · Score: 5, Interesting

    A lot of people are commenting on the fact that Intel's CEO sold the maximum permissible amount of company stock [or options - it isn't clear which] *after* Intel were notified of the bug and *before* this was made public.

    But I'm interested in this for a slightly different reason. In mid-December 2017 I purchased a new computer system. I had been saving up for it for a very considerable period of time... It is based around the Core i7-7700T processor, which I now understand to be one which will be impacted and likely to "slow down" as the patches for Windows and Linux are deployed.

    But Intel knew that the chip that I would be buying was materially defective. Whilst I accept that they have taken steps to apply corrective software fixes, that doesn't detract from the fact that I could have chosen to defer my purchase until a "clean" chip was released. Here we have the CEO saying "no recall", yet how are Intel's actions any different from i.e. the Ford Motor Company / Firestone Tire issue?

    Are Intel claiming that they have no legal obligation to sell working product? Or to take appropriate steps to notify customers in a timely manner? If they knew about this in October, has it *really* taken this long to get patches ready and come clean? And what about all the product already in the supply chain?

    I would be *very* interested to see any data from Intel's distributors or channel suppliers to get a better handle on shipment volumes in the time slot in question. Very interested to know if Intel made a push to "get rid" of known bad stock. Very interested to know what the lead time is for good silicon.

    Anyone got any real-world experience of these scenarios?

    1. Re:Question on Timing by 110010001000 · · Score: 1

      "But Intel knew that the chip that I would be buying was materially defective. Whilst I accept that they have taken steps to apply corrective software fixes, that doesn't detract from the fact that I could have chosen to defer my purchase until a "clean" chip was released. Here we have the CEO saying "no recall", yet how are Intel's actions any different from i.e. the Ford Motor Company / Firestone Tire issue?"

      You nailed the issue. In addition, Intel is STILL SELLING their defective product. Intel did the right thing (after being dragged kicking and screaming) and recalled their defective product after the FDIV issue. THere is no reason to think they won't have to this time. So there is real world experience and precedent here.

      Oh, and for the CEO dumping his stock issue? Just listen to the expert:"In all the years I've been at this and of all the companies I've covered, I can't recall another single massive sale on this scale," said Stacy Rasgon, an Intel analyst at Sanford Bernstein.

    2. Re:Question on Timing by Anonymous Coward · · Score: 0

      The CEO was informed of the issue in April. He filed for selling of his stock after that. So yes, it absolutely is clear that he sold his stock to cash out because their NSA fraud was made public.

    3. Re:Question on Timing by Anonymous Coward · · Score: 0

      In the UK, if you had the CPU less then six months then you should be able to return it. The retailer would be obliged to prove that the product is not faulty ... which I think that they would find almost impossible to achieve.

      The more interesting question is whether anyone in the UK tried to get a refund on Intel processors that are older than 6 months but less than 6 years. Here it is up to the consumer to prove the product is faulty, but the evidence for that looks pretty compelling.

    4. Re:Question on Timing by hankwang · · Score: 1

      Redesigning CPU logic at such a fundamentel level, manufacturing new litho masks, and ramping up production would take months if not over a year (if they have the capacity to manufacture so many new masks). And seriously, the fabs are running at close to maximum capacity; where would Intel get the capacity to produce repacements for all CPUs sold over the last few years on top of what they would be producing new?

      The best you may hope for is a rebate worth 10% of the replacement value of the CPU. And even that is unlikely to happen IMO.

    5. Re:Question on Timing by Anonymous Coward · · Score: 0

      Try to buy AMD CPU for your motherboard. If you can't, return CPU and motherboard and replace both. If you can't, you now have a case to sue Intel in small claims for the replacement value of your CPU + motherboard.

    6. Re:Question on Timing by Anonymous Coward · · Score: 0

      Most analysts are idiots and all are kids. Let the SEC decide. If it really is that big of a deal, what the CEO did was the definition of insider trading.

    7. Re:Question on Timing by ytene · · Score: 1

      Unfortunately, I think you may be right with respect to the amount of time and effort that it will take Intel to address the problem. Although to be honest, I don't know how extensive the redesign would be, how long it would take to run the test simulations, or the amount of lead time between taping out and shipping in volume.

      The issue, though, is the alternative. With something like a new television or a washing machine, if you buy a defective product and discover the fault within a reasonable time period, then you take the faulty product back to the store and claim either a replacement or a refund, sometimes both depending on the price of the replacement product.

      That is much harder to do when, basically, the only "replacement" I could use would be a pin-compatible chip. If the socket designs were common or changed infrequently, that might help me, but, sadly, my challenge is compounded because I am reliant upon the integral GPU in my chip to drive my displays [as are, for example, almost all modern laptops]. The challenge, therefore, is that the avenue of "replacement" - at least with off-the-shelf parts - is a non-starter. This almost certainly is the opposite of the case had the failed component been a optical drive, PSU, RAM, discrete GPU, discrete sound card or even motherboard. The chances are that I could get a replacement for pretty much *any* component other than the CPU.

      I haven't discussed it here, but what about any buyers who have purchased computers from resellers in which specific performance goals were stipulated in a purchase contract agreement and which, with the changes now being wrought, won't be met? [ OK, stupidly narrow use case, but I offer it to try and illustrate the question on liability. This is Intel's problem, plain and simple. Trying to palm off the responsibility of the fix on to the OS guys is despicable].

      All of these questions, however, are not germane to my original question. It's not what Intel choose to do *now* that matters quite so much as what they *didn't do* when they knew of the issue but it was otherwise witheld. I think [IANAL] that their actions in this time window may [and I'm hopeful here] force them to "do the right thing" and support the customers that they have shafted.

      We'll see, I guess...

    8. Re:Question on Timing by denbesten · · Score: 1

      In mid-December 2017 I purchased a new computer system. ... I could have chosen to defer my purchase until a "clean" chip was released.

      You are more fortunate than most of us. Being under 30 days post-purchase and under 14-days post-Christmas, most retailers are likely to accept a return. Plus, you likely have a warranty to possibly make a claim under. My now 4 year old computer has none of that.

    9. Re:Question on Timing by thegarbz · · Score: 2

      Anyone got any real-world experience of these scenarios?

      I invite you to look at a history of erratas from any CPU (or silicon in general) manufacturer. It is literally situation normal to sell devices with known defects that need to be worked around, and it has been since the 80s.

      The problem with your "defer" option is that you're unlikely to defer when there's no end in sight.

    10. Re:Question on Timing by ravenshrike · · Score: 1

      It's worse when you consider that Intel launched a new series of CPUs after they were aware of the defect. They should be fined all the profit made from those CPUs and be forced to give out rebates as well from a separate fund.

    11. Re:Question on Timing by 110010001000 · · Score: 1

      This isn't a simple "errata". It is the biggest processor flaw seen to date.

    12. Re:Question on Timing by Anonymous Coward · · Score: 1

      Nothing in Spectre or Meltdown exploits anything where the Intel or any other CPU (that I'm aware of) doesn't follow the ISA documentation. The Intel processors (ignoring unrelated errata that every stepping of every CPU always has) are doing exactly what is advertised so the product is not faulty.

      The fact that there is a covert channel is unfortunate and it's more unfortunate that the channel is so easy to access.

      I think my intuition would have been to seriously question the delay of the access check if I were on the design team just because it "seems" like doing it this way has a higher potential to expose a covert channel, but until someone proves that such a exploit is possible, it's not unreasonable to continue doing so.

      If someone figures out an exploit that is based on getting the CPU to work harder depending on some value in some location in memory to which the "reader" has no access and then detect the resulting slowdown due to throttling by thermal management to intuit, even roughly, what value is in the location, would we then all be running around screaming "Oh no, Intel shouldn't have implemented thermal management, I want a version of the CPU that doesn't do that"? I hope not.

    13. Re:Question on Timing by ytene · · Score: 1

      That solution might have worked maybe 20 years ago, when the likes of Cyrus produced chips that were plug-compatible with the Intel PCs of the day.

      Unfortunately, however, since AMD and Intel use chips with different pin layouts, motherboard with sockets that fit Intel chips simply won't fit an AMD chip of any kind... Were it only that simple!

      In fact, of all the components to be found inside the modern PC, the processor is the one restricting factor: I can buy from a wide range of manufacturers if I want to change a motherboard, sound card, graphics card, RAM, optical drive, power supply, SSD or hard drive ... but if I want a CPU, then I have no choice but to go to the same manufacturer for which the socket fitted to my motherboard was designed.

      Yes, I might be able to swap both motherboard and CPU [at considerable expense], but in my circumstances the case I am using - an Impactics fanless case specifically chosen because it is completely silent - may be a limiting factor. If I can find a decent AMD motherboard that supports the Mini-ITX standard, however, I will definitely consider it... And, of course, if there is an AMD processor out there which has equivalent on-chip graphics to the HD Graphics 630 found on my 7700T and which is currently driving my monitors...

    14. Re:Question on Timing by Anonymous Coward · · Score: 0

      I haven't discussed it here, but what about any buyers who have purchased computers from resellers in which specific performance goals were stipulated in a purchase contract agreement and which, with the changes now being wrought, won't be met? [ OK, stupidly narrow use case, but I offer it to try and illustrate the question on liability. This is Intel's problem, plain and simple. Trying to palm off the responsibility of the fix on to the OS guys is despicable].

      All major CPU manufacturers of popular modern CPUs have, for decades, "palmed off" responsibility for fixes on the OS -- check the errata for any stepping of any such CPU and you will find numerous errata that require one or more OS or hardware vendors to work around because the ISA spec isn't quite met (and, in this case, I don't think the ISA spec was violated).

      As far as performance commitments, the mainline non-realtime OS's don't guarantee performance and, over time, most patches except those for performance problems tend to degrade performance. Unless you develop your own OS, you'd be a fool to put a clause about performance in a contract without caveats that it does not apply to hardware firmware updates and/or OS updates which may be desired for reliability but which you don't control.

      It is also quite possible that Intel couldn't figure out, for the latest generation of chips, HOW to provide a replacement CPU that is as efficient (power and speed) as the one being replaced but doesn't have at least some form of the Meltdown vulnerability - it would probably require more and "more efficient" (smaller feature size for example) "silicon" that any but the next tick (or is it tock?) still in the development pipeline offers. Probably they could achieve this after the next generation of chips is already out and their performance boost, along with the patches for Meltdown, would already be as fast or faster as the prior generation in most cases. But, by that time, how many critical uses (those really effected by the patches in a noticeable way) would not already be starting an upgrade cycle for power and footprint reasons alone?

      Since Spectre impacts most modern complex CPUs is not something that the CPU vendors will have any responsibility for in existing designs because speculative execution is an industry standard. For a car analogy, if someone discovers that adding two more wheels to cars makes them much safer, all existing cars wouldn't be recalled and replaced with new ones with two extra wheels.

      I'm curious if all the people here, most of whom seem to be software oriented (as I am), would accept the same standard for their software. This would effectively require a full refund (potentially including the cost of the system on which it runs given the arguments that "oh my motherboard is designed for only this CPU") for a potentially obsolete version of software if a security or correctness bug is found and the fix degrades performance.

  36. Not entirely absurd by Tablizer · · Score: 1

    A recall doesn't have to be all-or-nothing. Intel could at least make an effort to replace the worse-affected situations.

    If they advertised a certain performance and their design flaw makes that performance not possible, it's legally breach of contract and/or false advertising. They don't automatically have a get-out-of-punishment card JUST because of the magnitude of the mistake. "It's too hard to uphold" is not a sufficient excuse. There is a continuum of resources and effort they can provide to replace bad chips.

    I agree they shouldn't be forced to commit corporate suicide via mass recall, but they should at least be court-forced to make a strong effort if they failed to deliver on their performance claims. I expect a class-action lawsuit and some kind of upper-limit of payouts agreed to so as to not outright kill the company.

    1. Re:Not entirely absurd by Jeremi · · Score: 1

      f they advertised a certain performance and their design flaw makes that performance not possible, it's legally breach of contract and/or false advertising.

      Except that their traditional level of performance is still perfectly possible -- just don't install the anti-Meltdown patches, and you'll have a system that runs at full efficiency. It will be insecure against Meltdown attacks, of course, but no more insecure than it was 5, 10, or 15 years ago... and AFAIK Intel never promised anyone perfect security anyway.

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    2. Re:Not entirely absurd by Tablizer · · Score: 1

      just don't install the anti-Meltdown patches, and you'll have a system that runs at full efficiency. It will be insecure against Meltdown attacks, of course...

      That would be for a jury to decide. Without the patch it's clearly not useful for many types of systems and probably typical systems because hackers are quite likely to exploit the problem now that it's exposed.

      But something tells me there is probably "wiggle language" in Intel's contracts. After the famous "Pentium math bug" in the 90's, they probably put wiggle language in all contracts and licenses.

    3. Re:Not entirely absurd by Anonymous Coward · · Score: 0

      but no more insecure than it was 5, 10, or 15 years ago

      Total bullshit. This exploit is out there *now*, it was not out there *5 years ago*. So your system is now *wide open* if you don't apply the patch and *degraded* if you do.

      How much is Intel paying you people?

  37. Meltdown hardware fix by Anonymous Coward · · Score: 2, Informative

    This isn't a simple errata. This is HUGE flaw, a true game changer. It is a flaw that CANNOT BE FIXED, only mitigated to some extent.

    Meltdown CAN be fixed. You simply change the VHDL / Verilog code to do access check BEFORE the speculative execution and NOT AFTER.

    You know, like AMD does it.

    (Spectre is another matter.)

    1. Re:Meltdown hardware fix by 110010001000 · · Score: 1

      You cannot make that change in the microcode. Meltdown cannot be fixed without replacing the processor: it can only be mitigated.

    2. Re:Meltdown hardware fix by Anonymous Coward · · Score: 0

      Make clflush a noop in ring 3 (may silently break stuff) or make it trap (loudly breaks stuff). Should be doable in microcode. Why is this thing unprivileged anyway?

    3. Re:Meltdown hardware fix by Anonymous Coward · · Score: 0

      Hmm, would still allow to break out of guests into hypervisors. Bleh.

  38. Wanna bet? by dcollins117 · · Score: 1

    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.

    Yes, it is. Their initial response to the FDIV bug was that it was a rarely used instruction so they wouldn't be replacing the chips. I got mine replaced, and will be getting new processors this time too. It all depends on how tenacious you are. If if costs them less to replace the chips than to deal with you they will replace them.

  39. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  40. That's totally irrelevant. That's a straw man. by Anonymous Coward · · Score: 0

    Nobody said FOSS has never had flaws. What is being said is that with proprietary software, you have NO CHOICE but to depend on the good graces of other people who have no real incentive to care about your particular situation.

    Get it yet?

  41. Buying AMD from now on by DogDude · · Score: 1

    From now on, we'll only be buying AMD-based machines. Buh-bye, Intel!

    --
    I don't respond to AC's.
    1. Re:Buying AMD from now on by Anonymous Coward · · Score: 0

      There are reasons for buying AMD (assuming that you mean CPUs, not stock) but the current situation is not one of them. AMD chips have flaws as well. If you're really being careful you look at the revealed list of errata for the chips that you are considering, and keep in mind that new errata may be published any time.

  42. how bad is it? by stabiesoft · · Score: 1

    OK yes it is bad, but how does someone running a desktop/laptop get hit? In order to exploit the bug, wouldn't another process not of your knowing have to be running? I get it is a major issue for cloud machines where they are sliced and diced for multiple users, but my machine I don't see it. If I have processes running that are foreign that are not standard system processes, I think I have bigger problems than this to worry about.

    1. Re:how bad is it? by Anonymous Coward · · Score: 0

      OK yes it is bad, but how does someone running a desktop/laptop get hit?

      Javascript. That is 99% of the attack surface for your use case. There are no real fixes to stop all Javascript attacks.

      Block all Javascript forever and you'll be fine. Shame you won't be able to use half your favourite websites though.

    2. Re:how bad is it? by Anne+Thwacks · · Score: 1
      wouldn't another process not of your knowing have to be running?

      Yes - that is what Javascript is!

      --
      Sent from my ASR33 using ASCII
  43. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  44. Turn based Strategy games are by rsilvergun · · Score: 1

    Heavy on IO. CPU turns are taking longer. I gather if you play the really huge and poorly optimized Grand Strategy games it's a problem. He tells me folks on the forums are already complaining. There's also been some scattered reports on the Ghost Recon Wildlands forums of big hits to frame rates, but it's pretty random. Some folks saw no difference post patch and others went from 60 to the mid 40s.

    --
    Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
    1. Re:Turn based Strategy games are by thegarbz · · Score: 1

      No where did you get the benchmarks from? I've seen plenty of scattered reports ranging from nothing all the way to end of days. But so far the only benchmarks I've seen are Arstechnica who put a test PC through every benchmark they could find before and after and showed little more than an unnoticeable drop in performance.

  45. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  46. I think they didn't even issue a microcode patch. by Anonymous Coward · · Score: 0

    I've read this over a couple of times and I think they are "spinning" their announcements to make it sound like they issued a fix via microcode, but what actually happened is they heavily contributed to the software level patches that have been made for Meltdown. Was kind of funny to see that this fix was then updated by an AMD guy to basically disable it if the CPU is an AMD one (because Meltdown doesn't impact them.)
    I think at this point no one has implemented any kind of fix for Specter (which affects AMD, Intel, ARM, etc)?

  47. CEO cashed out when he found out by WillAffleckUW · · Score: 1

    It's in the SEC filings that the CEO cashed out a larger than usual quantity of stock option exercises and then sold them, starting literally the day he found out about the flaws.

    Trust him if you want, but as a longtime tech investor, I wouldn't.

    --
    -- Tigger warning: This post may contain tiggers! --
  48. Devil's Advocate by sl3xd · · Score: 1

    To play devil's advocate: I don't know of a single chip that doesn't have errata published by the manufacturer. The first "real" lesson I learned in my EE career is "you can't take the manufacturer's documentation at face value."

    The important thing is how problems are handled, and I don't know of any chip maker who handles bugs like this well.

    When their GeForce 8600M had issues with overheating and dying, NVIDIA first blamed notebook manufacturers, and later the foundry. It was later found to be a problem with NVIDIA's silicon layout. Apple had to replace millions of MacBooks whose NVIDIA card died after less than a year (Ever wonder why Apple uses AMD graphics these days?)

    Even AMD has issues when it goes into CYA mode: Back in the day, AMD had major TLB issues with their Phenom processor. At the time AMD claimed the "... TLB erratum is a highly random event that would not occur during normal desktop usage and we've never encountered it during our testing of Phenom." "Normal desktop usage" was defined to exclude a Xen hypervisor running Windows XP, or running the SPEC 2006 benchmark -- not exactly common, but they're clearly doing the PR spin.

    Then there's Intel... Some serve as an example of others to follow. Others serve as a warning to others.

    In the past two months alone, from serious bugs in the Intel Management Engine to Meltdown, they've done a great job serving as a warning.

    --
    -- Sometimes you have to turn the lights off in order to see.
  49. What about root kits? by tuorum · · Score: 1

    Could a root-kit using VT bypass this for the guest if it was specifically built to not include any of these "fixes"?

    1. Re:What about root kits? by sl3xd · · Score: 1

      I'm not quite sure what you mean by "VT" -- do you mean Intel's VT-x?

      It's probably best to let the Xen folks explain far better than I could hope to.

      Quemu has their own explanation (and I think KVM is included in the explanation)

      I get the feeling that the virtualization instructions (VT-x, AMD-V, and whatever the equivalents are on s390, ARM, and POWER) aren't really involved with either Spectre or Meltdown.

      I wonder about SPARC, but given Oracle & Fujitsu appear to be killing SPARC... it probably doesn't matter.

      --
      -- Sometimes you have to turn the lights off in order to see.
  50. Lawsuits on what processor? by Anonymous Coward · · Score: 0

    RISC-V may or may not depending upon implementation.

    https://www.reddit.com/r/RISCV/comments/7nzd5c/is_riscv_affected_by_meltdown_andor_spectre/

  51. Re: ARM affected too, confirmed by ARM by Anonymous Coward · · Score: 0

    You're the one who's wrong. ARM themselves note that Cortex A57, A72, A75 and A15 processors are affected by CVE-2017-5754 which is the Meltdown CVE (Spectre is CVE-2017-5753 and CVE-2017-5715)

  52. Same bet as VW by Anonymous Coward · · Score: 0

    OOSE (Out of order speculative execution) is basically making a statistical bet that the majority of a workflow will go a certain way. One that gives increased performance. Meltdown took some of the time-consuming checks and moved them from the "check first" to the "check after the fact" which is fine as long as your bet that things go a particular way remains true. The exploit consistently broke that bet.

  53. Big-Boy Companies don't need to 'Prioritize' by Spinlock_1977 · · Score: 1

    "... to determine which ones to prioritize based on what they see as systems in the field"

    How about taking responsibility for all of them, right now?

    --
    - The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
  54. Programming on what grounds? by Anonymous Coward · · Score: 0

    Sounds like the hardware version of OOPs with some of the same problems.

  55. Simulations with what tools? by Anonymous Coward · · Score: 0

    Has anyone ever used SHENZHEN I/O to simulate Meltdown and Spectre?

  56. Probably only in the US by Anonymous Coward · · Score: 0

    As usual Canada, UK, Australia, India, et al are screwed

  57. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  58. Intel Has Already Signaled Its Position by Anonymous Coward · · Score: 0

    Read the press and disclosure releases carefully. Spectre in some form is a potential issue with any processor that uses speculative execution. EVERY Intel CPU since at least the Pentium Pro does that. Meltdown is a little more specific to Intel because its architecture is more aggressive about speculative execution than some others - giving better IPC but opening up access to this attack. Intel's position is that these are not bugs in the processor - the processor is operating exactly as designed. But the fixes slow down the processor so people are going to see this as CPU bugs. Security == go slower, right? And Intels competitors *are* a tad slower at IPC, though more resistant in general to these attacks (especially Meltdown). Still nothing even remotely modern in terms of CPU design is completely immune to at least Spectre in some form, even mainframes and supercomputers - THAT is why this is fundamentally unfixable at the hardware or, probably, even the microcode level, unlike the older bugs. A whole new kind of CPU design is needed to avoid the problem, not just a faster version of what's already done.

  59. Someone needs to mod your posts up by Anonymous Coward · · Score: 0

    Everything I've read on this so far backs you up 100%.

  60. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  61. Sucking dick for coke money by c.d. reimer by Anonymous Coward · · Score: 0

    Chris you work for a shady IT bodyshop that has been hired by the FBI. You DO work in the private sector.

    It just feels like you work for the government because you have to deal with low pay, self important career bureaucrats, urine tests, and invasive background investigations. Your job could go away the second someone decides they don't like you and decides your online activity constitutes a failure to not talk about your work on social media or someone decides to make an issue of your alleged paedo tendencies.

    "Security" is a classic go-to excuse to give the ditch diggers and coal miners when they start wondering why it is they work so hard for the man in return for so little. If you had an actual good job nobody would ever have a prepared list of reasons why it's so good to work there. Security works for you because you always, always always get fired^H^H^H^H your contract ends and it's not renewed.

    Do you really think you weren't fired from your other jobs? I had a chum who was constantly getting 6 month contracts "not extended", because he was no fun to be around and it was obvious he was on drugs. But he sincerely believed that he was just picking up six month contracts and finishing them.

    The worst part is he started getting better and better jobs, essentially getting a small promotion every 8 months. But eventually he burned every major bodyshop in Austin and had to start sucking dick for coke money.

  62. Impact to PC Manufacturers? by ytene · · Score: 1

    Another random thought here... Thinking about all the manufacturers of systems - Dell, HP, Lenovo, Apple, the list goes on - who currently have tens of thousands of built machines sitting in warehouses, or in shipping containers in transit, or in stores waiting to sell... which have this bug in them.

    What would happen if the general public collectively decided, "Nope. Not going to buy it with a bug in there. We'll wait for new generation processors, thanks..." ???

    Sadly, I think this is unlikely to happen, but I wonder if something like that could get the channel integrators to put enough pressure on Intel to offer replacements? And, if you were a channel integrator, what would you do with all your Intel stock that you haven't already fitted to a system?

  63. Surprise. by Anonymous Coward · · Score: 0

    It's because they're not bugs, they're features they were told to put in.

  64. Agreed by ytene · · Score: 1

    At the very least...

  65. Intel would be bankrupted if they did a recall... by Anonymous Coward · · Score: 0

    You can do the simple math of their financials: they don't have enough assets on their balance sheet to replace every Intel processor sold since the Pentium, which is the scope of this bug! It would bankrupt Intel to replace them.

    As it is, the decline of the PC in the consumer market has already hurt Intel. This would be the end.

  66. You are wrong on all counts by Brannon · · Score: 1

    > Security is like virginity: indivisible. You can't be "just a little bit insecure".

    This is the most false statement I have ever heard on /., and that's saying something. There is NO such thing as perfect security. All you can do is raise the cost, time, & effort required to defeat the security measures. This is true for every kind of security that has ever existed in the history of mankind.

    > Note that the remedies for Meltdown will more than wipe out the performance gains obtained by the ill-advised speculative execution.

    You really have no idea what you're talking about. Turn off OoO execution and performance slows down dramatically. Turn on KPTI and performance slows down negligibly.

    It's clear you don't understand computer architecture, engineering, or basic security principles.

  67. Kindly Do the Needful and Revert Back by Anonymous Coward · · Score: 0

    Sorry, that's not on the cards

    That's OK as long as it's in the cards.

  68. Intel Doesn't have a Remedy by I75BJC · · Score: 1

    How can Intel replace all these effected CPUs when there is not a replacement? It seems that the /. and other communities have gone stark raving mad. There is no hardware fix. Life is a dangerous adventure. It doesn't matter what "Mother" tells you -- you live in an unsafe world and an unsafe computing environment. The best attempts by any person and even by Intel will always fall short in providing a truly "Safe" world or computing environment will Never happen. Even the courts and legislatures can't change this. As the Eagles sang, "Get over it!" And get on with a real & authentic life -- take responsibility for your own happiness, etc.