Closed

Intel Disputes CPU Bug Claims

Intel's silence on the "bug" was deafening over the last 24 hours as the story unfolded, but now the company has issued a statement that contends there is, in fact, no bug at all.

Intel Disputes CPU Bug Claims : Read more
34 answers Last reply
More about intel disputes cpu bug claims
  1. Directly from AMD

    "AMD processors are not subject to the types of attacks that the kernel
    page table isolation feature protects against. The AMD microarchitecture
    does not allow memory references, including speculative references, that
    access higher privileged data when running in a lesser privileged mode
    when that access would result in a page fault.

    Disable page table isolation by default on AMD processors by not setting
    the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
    is set."
  2. Though the doomsday scenario may be overblown, you must also consider that Intel has a vested interest in downplaying the impact if any, as well as implicating as many other competitors as possible. I think we need to wait and see.
  3. Hang on, what windows tests? almost every single test posted online abvout the patch was of linux.

    Also the language you're using in both articles almost seems like you were paid to protect intel.

    Also the intel verbiage seems to be trying to claim other processors have this flaw, which AMD said its false.
  4. tamalero said:
    Hang on, what windows tests? almost every single test posted online abvout the patch was of linux.

    Also the language you're using in both articles almost seems like you were paid to protect intel.

    Also the intel verbiage seems to be trying to claim other processors have this flaw, which AMD said its false.


    The Windows tests are linked in the text. https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

    AMD has not released a statement about the vulnerabilities.

    ARM disclosed a few minutes ago that it also is subject to the vulnerability. The company claims the vulnerability is not the the result of "Architectural flaws."

    We will update the post when AMD makes an official statement.
  5. "this implies the exploit can read data" It's just me but imagine what CIA could have done with this all over the world. But I'm sure CIA didn't have idea about this... or maybe not?
  6. making popcorn...
  7. Haha, where's your post patching Benchmarks? Until you complete those and publish them, all this smacks of paid protection of Intel stock prices.
  8. silverwolf.bwc said:
    Haha, where's your post patching Benchmarks? Until you complete those and publish them, all this smacks of paid protection of Intel stock prices.


    https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

    These are preliminary results. Computerbase.de has a solid history of accurate test methodology.
  9. What about Cloud providers? They must be shaking in their shoes. Customer A can use this exploit to read data from Customer B.
  10. Yep the bug is real and by early estimates there’s a huge 30% cpu penalty to fix this hardware flaw, OS doesn’t matter

    Good thing I have my Ryzen
  11. Yup. I am sure this is COMPLETELY overblown. And the MASSIVE sale of stock by the CEO in November (when the bug was 1st discovered)? Purely coincidence! Right? RIGHT???
  12. I'm not sure the reporting on this issue today has given much credibility to tech writers. As this back and forth evolved they ended up letting Intel run the PR and damage control machine and the writers got played like a fiddle. Although implicating ARM and AMD succeeded in raising fear, uncertainty and doubt - and moving markets - the fact remains that the most serious issue remains an Intel specific issue whose fix will have some unknown implication ranging from zero to substantial. I don't find that consistent with the statement that all modern CPU manufacturers are equally vulnerable.
  13. This year is gonna be a blast. security holes EVERYHWERE. Intel then Apple then Samsung. I love my tinfoil hat and popcorn.

    PS If what is stated by Intel is not true, or I will be affected in any way by the patch they are not going to see money from me never again.
  14. Intel's statement is an outright, purposeful deception. They brought up the spectre of data modification and completely avoided mentioning the actual bug, which is the ability to read the contents of kernel memory, when not a single person was talking about data modification and everyone was talking about the ability to read kernel memory. Being able to read kernel memory completely destroys the security of the machine, period. You don't NEED to be able to modify memory when you can steal the encryption keys!

    Intel then went on to try to include all other cpu vendors in their little party, to make it seem like it was normal or at least not something Intel-specific. Except this bug *IS* Intel-specific. AMD doesn't suffer from it. ARM doesn't suffer as badly. Sure, there are generally some issues due to speculative timing attacks. But this bug on Intel is the thousand-pound gorilla and they are playing light with it in their statements.

    And also in statements, Intel is trying to pass-off the 'fix' that all of us OS programmers have to do, as being something minor. It isn't minor. We have to completely destroy user->kernel transition efficiency by changing out the MMU page tables (%CR3 reload) for every user->kernel and kernel->user transition. THAT SUCKS ROCKS! 150ns system call overhead increases to over 400ns. that isn't minor. That's a show-stopper.

    It may be that some classes of problems won't care so much, because they don't make a lot of system calls or take a lot of interrupts, but I guarantee you that there are a LOT of classes of problems that do care, particularly on the server side and in the cloud. I sure as hell care. Intel is wasting god knows how many millions of man hours of people's time dealing with this junk.
    All because Intel can't get its house in order. First the management engine, then the hyper-threading bug, and now this junk. I'm sick and tired of it.

    -Matt
  15. It seems that the author of this article fell for Intel's PR bait hook, line and sinker. In particular the deliberately misleading mention of AMD, which does not suffer from this 'not a bug'. Interesting that the author feels compelled to claim that any performance issues will be addressed over time, when the design fault ('not a bug') can only be avoided by turning off an essential element of the CPU's functionality.
  16. PaulAlcorn said:
    tamalero said:
    Hang on, what windows tests? almost every single test posted online abvout the patch was of linux.

    Also the language you're using in both articles almost seems like you were paid to protect intel.

    Also the intel verbiage seems to be trying to claim other processors have this flaw, which AMD said its false.


    The Windows tests are linked in the text. https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

    AMD has not released a statement about the vulnerabilities.

    ARM disclosed a few minutes ago that it also is subject to the vulnerability. The company claims the vulnerability is not the the result of "Architectural flaws."

    We will update the post when AMD makes an official statement.


    AMD has submitted a patch for Linux to prevent the fix being applied to their processors, since it is not necessary:

    https://lkml.org/lkml/2017/12/27/2
  17. deesider said:
    PaulAlcorn said:
    tamalero said:
    Hang on, what windows tests? almost every single test posted online abvout the patch was of linux.

    Also the language you're using in both articles almost seems like you were paid to protect intel.

    Also the intel verbiage seems to be trying to claim other processors have this flaw, which AMD said its false.


    The Windows tests are linked in the text. https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

    AMD has not released a statement about the vulnerabilities.

    ARM disclosed a few minutes ago that it also is subject to the vulnerability. The company claims the vulnerability is not the the result of "Architectural flaws."

    We will update the post when AMD makes an official statement.


    AMD has submitted a patch for Linux to prevent the fix being applied to their processors, since it is not necessary:

    https://lkml.org/lkml/2017/12/27/2



    AMD, Google, ARM Holding, and Microsoft have all now issued statements. AMD responded directly. The company does suffer from a one variant of the vulnerability (Bounds Check Bypass), but the company claims it is "Resolved by software / OS updates with negligible performance impact." Intel, of course, is claiming the same, but the company suffers from three variations of the vulnerability.
    Google has already patched its infrastructure.
    As we said in the closing lines of the article:

    Quote:
    Intel's statement opens the floor for other companies to weigh in with their version of events. We'll follow up as more details emerge.
  18. Thanks, Paul, for the article and a followup to all the news circling around this issue.
  19. On a scale of 1 to 10, I'm somewhere around a 6.5-7 that Tom's is in the bag for Intel.
  20. Someone is making bank right now.
  21. ldcsteelers said:
    What about Cloud providers? They must be shaking in their shoes. Customer A can use this exploit to read data from Customer B.

    This.

    Software running in one virtual machine can read the memory of another virtual machine on the same host.
  22. Question is for how long did Intel know about these vulnerabilities? If some forums are to be believed it's not a new issue as some white hat hackers have already alluded to the problem in the past. According to their claim this bug is generated from the kernel space allocation/mapping routine which is handled by processor MMU. Intel's method of doing this leaves the kernel memory somewhat accessible (readable) from the userspace which compromises the security of the entire system through possible TLB (translation lookaside buffer) side channel exploits. Again, the question is what took Intel this long to address this critical issue?
  23. "Those preliminary tests reveal that there is , with synthetic I/O tests inflating the issue."
    There is a problem with this sentece.
  24. Quick question: does this apply to all Intel CPU's or just certain Gen's?
  25. It's a BUG in all Intel CPU's from the last... ready for it.. Decade!
  26. faalin said:
    Quick question: does this apply to all Intel CPU's or just certain Gen's?


    All existing Intel CPUs is what I saw. Someone could correct me if I am wrong.
  27. Come on Intel I still have your old Pentium 60 with the bad math bug. How long did it take to fess up on that? O the programmers can make work around I think was one of those desputes. What was that division formula to prove the math bug?
  28. This affects ALL Intel CPUs back to 1995. Over 20 years this problem has been around and because it won't leave any fingerprints on the system we have no way of knowing if this has been exploited or not.
  29. https://en.wikipedia.org/wiki/Pentium_FDIV_bug

    The Wikipedia link above has a good example.
  30. vapour said:
    faalin said:
    Quick question: does this apply to all Intel CPU's or just certain Gen's?


    All existing Intel CPUs is what I saw. Someone could correct me if I am wrong.
  31. Intel doesn't want you to know that every Intel processor since 1995 that implements out-of-order execution is potentially affected by Meltdown – except Itanium, and the Atom before 2013.
  32. Now that we have information from all sources we have posted an update.

    http://www.tomshardware.com/news/meltdown-spectre-exploits-intel-amd-arm-nvidia,36219.html
  33. Having been involved in the crypto-world the past few months, it's funny to read this line:

    Intel's stocks tumbled a whopping 7% earlier in the day as AMD skyrocketed to a 10% gain.
  34. Hmpf.

    So going with AMD 83xx processors my last two support-centered workstations (2013/2015) turned out to be a pretty good choice for the unforeseen future after all, eh?

    (Note. My PC use is primarily multi-tasking, not gaming, and is generally informed by budget constraints and the SSD cost factor at build time period - including spec'ing NVMe in 2015 - hence my decision. Overall performance was good enough comparably, so the absolute CPU performance of Intel mattered somewhat less than usual. Both workstation are still quite useful-to-the-purpose, although I'm already planning on a Ryzen or EPYC based system late this year, early next. It's time.)
Ask a new question

Read More

CPUs Intel