5 ms·

The Spectre attack had to be patched in the kernel in a way that significantly slowed down execution on Intel CPU:s: https://www.notebookcheck.net/Spectre-v2-mi

The Spectre attack had to be patched in the kernel in a way that significantly slowed down execution on Intel CPU:s: https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-havoc-on-the-performance-of-some-Intel-CPUs-as-AMD-chips-come-out-largely-unscathed.607925.0.html https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...

mike_hearn 3y ago
Yes, I think that's what I said? Every attack no matter how deep it seemed to be has been patchable in microcode, sometimes at a cost in performance. But so far nobody had to toss the physical silicon, at least not with Intel. The malleability of these chips is quite fascinating.
- rocqua 3y ago
  The meltdown and spectre mitigations weren't patched in microcode, they were patched by changing the internal calling methods of the kernel.
  - mike_hearn 3y ago
    I think it was both. There were initial software only patches, but those were quickly superseded by microcode+kernel patches, where microcode added features the kernel enabled. IBRS or something like that.
    - cbsmith 3y ago
      It was both, and none of them completely addressed the problem. They did need new hardware for that.
- sigotirandolas 3y ago
  On some Skylake CPUs to get full mitigations you are taking a 30% performance penalty _and_ you need to disable SMT which is often another double digit penalty. It's not a literal "toss the physical silicon", but it's getting there. In fact my thesis is that it's never a literal "toss the physical silicon" because the kernel is able to take control when switching between tasks so (with help from the microcode) it's able to wipe all potential speculation vectors (at an arbitrarily expensive cost) before switching to the next task. This also explains why SMT is unfixably broken on some processors, since by design the kernel does not intervene in the task switching on the virtual cores.
dmatech 3y ago
What's interesting is that the FDIV bug from 1994 could also be worked around, but Intel recalled and wrote off those processors[1]. For their latest several problems, their response was more of a "sucks to be you". While they provided microcode updates and worked with OS vendors, there were performance impacts that materially affected the value of the chips. 1. https://www.intel.com/content/www/us/en/history/history-1994-annual-report.html https://www.intel.com/content/www/us/en/history/history-1994...
- phire 3y ago
  The software workaround for the FDIV bug required the actual userspace software to be modified and recompiled. There was a decade of pre-existing software out there that would be hard to fix, especially in the days before most people had the internet. There was nothing the OS could do to work around the bug, short of disabling the entire FPU and falling back to expensive software emulation of all floating point math. The workarounds for all these speculation bugs can be mostly applied at the operating system and/or microcode level, and is comparably cheap.

mike_hearn 3y ago

Yes, I think that's what I said? Every attack no matter how deep it seemed to be has been patchable in microcode, sometimes at a cost in performance. But so far nobody had to toss the physical silicon, at least not with Intel. The malleability of these chips is quite fascinating.

rocqua 3y ago
The meltdown and spectre mitigations weren't patched in microcode, they were patched by changing the internal calling methods of the kernel.
- mike_hearn 3y ago
  I think it was both. There were initial software only patches, but those were quickly superseded by microcode+kernel patches, where microcode added features the kernel enabled. IBRS or something like that.
  - cbsmith 3y ago
    It was both, and none of them completely addressed the problem. They did need new hardware for that.
sigotirandolas 3y ago
On some Skylake CPUs to get full mitigations you are taking a 30% performance penalty _and_ you need to disable SMT which is often another double digit penalty. It's not a literal "toss the physical silicon", but it's getting there. In fact my thesis is that it's never a literal "toss the physical silicon" because the kernel is able to take control when switching between tasks so (with help from the microcode) it's able to wipe all potential speculation vectors (at an arbitrarily expensive cost) before switching to the next task. This also explains why SMT is unfixably broken on some processors, since by design the kernel does not intervene in the task switching on the virtual cores.

dmatech 3y ago

What's interesting is that the FDIV bug from 1994 could also be worked around, but Intel recalled and wrote off those processors[1]. For their latest several problems, their response was more of a "sucks to be you". While they provided microcode updates and worked with OS vendors, there were performance impacts that materially affected the value of the chips. 1. https://www.intel.com/content/www/us/en/history/history-1994-annual-report.html https://www.intel.com/content/www/us/en/history/history-1994...

phire 3y ago
The software workaround for the FDIV bug required the actual userspace software to be modified and recompiled. There was a decade of pre-existing software out there that would be hard to fix, especially in the days before most people had the internet. There was nothing the OS could do to work around the bug, short of disabling the entire FPU and falling back to expensive software emulation of all floating point math. The workarounds for all these speculation bugs can be mostly applied at the operating system and/or microcode level, and is comparably cheap.