Understanding The Meltdown And Spectre Exploits: Intel, AMD, ARM, And Nvidia

After two days of whirlwind developments, we finally have more of a complete picture of the new vulnerabilities that impact processors from the leading vendors. Reports initially surfaced two days ago that Intel's processors are susceptible to a new hardware-based bug that cannot be patched with a mere microcode update. A report from The Register, based in part on a blog post, said that incoming Windows and Linux patches would correct the vulnerability but come with a 5-30% performance loss depending on the workload.

The industry remained silent due to NDAs that were scheduled to expire on January 9, the same date as a round of patches were scheduled to appear. After a day of silence while its stock slumped, Intel issued a statement and claimed the issue is not a hardware bug. Intel also announced that it's working with other titans of the industry, such as AMD and ARM Holdings, to "develop an industry-wide approach to resolve this issue promptly and constructively." AMD has since released a statement and claimed that it has minimal exposure to the primary vulnerability.

Latest Videos FromTom's Hardware
Paul Alcorn
Editor-in-Chief

Paul Alcorn is the Editor-in-Chief for Tom's Hardware US. He also writes news and reviews on CPUs, storage, and enterprise hardware.

  • bennie101
    Wow that hard earn money we spent on intel cpus will come at a bigger cost now. I am sure they have know this issues for well over 20 years but Greed is the ROOT of aLL EVIL.
    Reply
  • jeremiah.moss
    A lot of people are claiming that gaming won't be affected, but that confuses me. You're making a lot calls from user space to the drivers, which should be in kernel space. We're not accessing the GPU from user mode directly, are we? Isn't this going through drivers and / or the HAL?
    Reply
  • -Fran-
    20557284 said:
    A lot of people are claiming that gaming won't be affected, but that confuses me. You're making a lot calls from user space to the drivers, which should be in kernel space. We're not accessing the GPU from user mode directly, are we? Isn't this going through drivers and / or the HAL?

    The problem lies (becomes exploitable) when you move in and out of memory spaces. So, if you don't have a malware running already and you are gaming, if the/a malware tries to access something without you making it run or force a switch of programs, nothing will happen since no memory will be moving (no randomized movement of memory addresses happen). So, the stuff put in the user memory address space will remain there without actually calling anything "new" to be put there from the kernel space (drivers should really be loaded at the start and not during gameplay). Now, for Streaming though. You are forcing several context switches there, so it will be interesting to see if it happens. The DX driver needs to send the data to another program residing in a different user space, so that implies moving memory.

    That is how I understand this problem, so feel free to correct me.

    Cheers!
    Reply
  • Mark RM
    Article was logical and well constructed, easy to follow and put the information in one place. Nicely done.Good piece of journalism there.
    Reply
  • ET3D
    Is there any indication that the Microsoft patch doesn't inflict an unneeded slowdown on AMD hardware? I know that Linus stopped that on the Linux side, but who's to say that Microsoft didn't just apply the fix to all architectures?

    20557284 said:
    We're not accessing the GPU from user mode directly, are we?

    Yes we are. That's what Microsoft changed in the driver model between XP and Vista. There is still a kernel component to the drivers, but much of the work is done in user mode, which both adds to OS stability (early NVIDIA Vista drivers notwithstanding) and benefits performance.
    Reply
  • InvalidError
    20557284 said:
    A lot of people are claiming that gaming won't be affected, but that confuses me. You're making a lot calls from user space to the drivers, which should be in kernel space. We're not accessing the GPU from user mode directly, are we?
    Most of the DirectX and other APIs' runtime is user-space and that's what typical software interacts with the most. Not every DirectX call results in a trip through a system call.

    In the case of server-style workloads that frequently involve the file system, IO and inter-process synchronization though, most of those have a very thin APIs that do little more than populate structures and do basic sanity checks before doing system calls.
    Reply
  • Myrmidonas
    I do not want to play the "devil's advocate" but, if he knew about the fault since last June he wouldn't sell on purpose for the case he would be accused for "abandoning ship" before it sinks. After all he is CEO from since May 2013. The flaws are rumored to be on most intel's chips many years before.
    Reply
  • anbello262
    Who bough intel stocks after the bug was announced? Was a ver good time for that!
    Reply
  • cryoburner
    Intel's statement on the matter specifically says that the exploits are not caused by a "bug" or a "flaw" that is unique to Intel products. Intel also noted that the exploits can "gather sensitive data from computing devices that are operating as designed."
    Exactly, it's not a bug. The backdoor has been functioning perfectly for decades. : 3
    Reply
  • redgarl
    Well, after Volkswagen scam, we have the Intel scam. It really doesn't look good for them in the fore coming future.
    Reply