5 ms·

What I find most disappointing is that even processors manufactured TODAY contain these flaws and have performance hits put into the firmware. This issue is so

What I find most disappointing is that even processors manufactured TODAY contain these flaws and have performance hits put into the firmware. This issue is so fundamental to how CPU caches work, that there really is not a true performance-neutral fix.

msbarnett 5y ago
> What I find most disappointing is that even processors manufactured TODAY contain these flaws and have performance hits put into the firmware. The first (private) disclosure of the Spectre vulnerabilities was sometime in mid-late 2017. Partial hardware mitigations launched in 2019 for some Spectre variants, where the mitigations could be easily patched in to already taped-out designs. Beyond those easy wins, even if foundries weren’t slammed by COVID delays, I don’t think it’s realistic to expect that we’d be any further along? Most of these sidechannels require deep rethinks of the execution pipeline and speculation engines, and fundamentally redesigning those systems, taping out those designs, and finally manufacturing those chips was always going to be a process that was measured in the better part of a decade.
tyingq 5y ago
I've seen a research paper that talks about something called "DAWG" that is supposed to preserve speculative execution while mitigating timing attacks. With some performance hit, but less than what we have today. The graphs in the paper seem to suggest a hit of 10% or less. Not my area of expertise, so no idea how promising it is. https://people.csail.mit.edu/vlk/dawg-micro18.pdf https://people.csail.mit.edu/vlk/dawg-micro18.pdf
userbinator 5y ago
What I find most disappointing is that even processors manufactured TODAY contain these flaws and have performance hits put into the firmware. Alternatively: if you don't care about timing side-channels (which is true in a lot of applications where the only code being run is trusted, such as with HPC clusters and the like), you can run at full performance, and if you do, you can load the microcode to increase the security at the expense of performance.
zargon 5y ago
An alternative interpretation is that there are no current "performance hits", just the legitimate performance is now (better) known. Those former "performance gains" were cheated, akin to Volkswagen emissions tests. Edit: it was Volkswagen not Volvo.
- johncolanduoni 5y ago
  It’s news to me that Intel, AMD, and various ARM licensees all knew about these problems (and vague “the ~truth~ side channels are out there” handwaves that were made for many years don’t count) when the requisite speculation changes were made 20 years ago and left them in anyway. And that still isn’t quite an equivalence to the Volvo emission tests, since the processors don’t try to detect if you’re testing them and change behavior.
  - zargon 5y ago
    It's my understanding that the bulk of the vulnerabilities in question are not present to near the degree on AMD and ARM. If AMD and ARM could do things mostly properly, why couldn't Intel?
    - rincebrain 5y ago
      There are a number of the vulnerabilities that affect other platforms than Intel x86 (including some POWER and ARM), though you're correct, a good amount of those disclosed are specific to Intel. But there has also been at least one that was AMD specific, too.[1] I hypothesize it could have come down to "well, we made this type of decision this way before, and the world didn't fall down, so we can probably make it that way again, right?" Since these aren't formally proven systems, to some extent deciding whether an optimization is safe is going to be a judgment call - and if you go for "well, if this assumption is false, we're already doomed because we did X elsewhere...", the results could look like this. Or maybe not, I've never worked for a chip design house. [1] - https://mlq.me/download/takeaway.pdf https://mlq.me/download/takeaway.pdf
      - 5y ago
drpixie 5y ago
The Spectre/Meltdown issues are fundamental and "difficult" to fix - but mostly exist because we can observe state using very fine grained performance counters. Why not disable (or dumb down) the performance counters, and leave the bugs and better performance in place? We could enable the counters (and the mask bugs and reduce performance) by normally-off a BIOS flag. I for one would rather have the performance and don't need the counters for day-to-day ops.

msbarnett 5y ago

> What I find most disappointing is that even processors manufactured TODAY contain these flaws and have performance hits put into the firmware. The first (private) disclosure of the Spectre vulnerabilities was sometime in mid-late 2017. Partial hardware mitigations launched in 2019 for some Spectre variants, where the mitigations could be easily patched in to already taped-out designs. Beyond those easy wins, even if foundries weren’t slammed by COVID delays, I don’t think it’s realistic to expect that we’d be any further along? Most of these sidechannels require deep rethinks of the execution pipeline and speculation engines, and fundamentally redesigning those systems, taping out those designs, and finally manufacturing those chips was always going to be a process that was measured in the better part of a decade.

tyingq 5y ago

I've seen a research paper that talks about something called "DAWG" that is supposed to preserve speculative execution while mitigating timing attacks. With some performance hit, but less than what we have today. The graphs in the paper seem to suggest a hit of 10% or less. Not my area of expertise, so no idea how promising it is. https://people.csail.mit.edu/vlk/dawg-micro18.pdf https://people.csail.mit.edu/vlk/dawg-micro18.pdf

userbinator 5y ago

What I find most disappointing is that even processors manufactured TODAY contain these flaws and have performance hits put into the firmware. Alternatively: if you don't care about timing side-channels (which is true in a lot of applications where the only code being run is trusted, such as with HPC clusters and the like), you can run at full performance, and if you do, you can load the microcode to increase the security at the expense of performance.

zargon 5y ago

An alternative interpretation is that there are no current "performance hits", just the legitimate performance is now (better) known. Those former "performance gains" were cheated, akin to Volkswagen emissions tests. Edit: it was Volkswagen not Volvo.

johncolanduoni 5y ago
It’s news to me that Intel, AMD, and various ARM licensees all knew about these problems (and vague “the ~truth~ side channels are out there” handwaves that were made for many years don’t count) when the requisite speculation changes were made 20 years ago and left them in anyway. And that still isn’t quite an equivalence to the Volvo emission tests, since the processors don’t try to detect if you’re testing them and change behavior.
- zargon 5y ago
  It's my understanding that the bulk of the vulnerabilities in question are not present to near the degree on AMD and ARM. If AMD and ARM could do things mostly properly, why couldn't Intel?
  - rincebrain 5y ago
    There are a number of the vulnerabilities that affect other platforms than Intel x86 (including some POWER and ARM), though you're correct, a good amount of those disclosed are specific to Intel. But there has also been at least one that was AMD specific, too.[1] I hypothesize it could have come down to "well, we made this type of decision this way before, and the world didn't fall down, so we can probably make it that way again, right?" Since these aren't formally proven systems, to some extent deciding whether an optimization is safe is going to be a judgment call - and if you go for "well, if this assumption is false, we're already doomed because we did X elsewhere...", the results could look like this. Or maybe not, I've never worked for a chip design house. [1] - https://mlq.me/download/takeaway.pdf https://mlq.me/download/takeaway.pdf
    - 5y ago

drpixie 5y ago

The Spectre/Meltdown issues are fundamental and "difficult" to fix - but mostly exist because we can observe state using very fine grained performance counters. Why not disable (or dumb down) the performance counters, and leave the bugs and better performance in place? We could enable the counters (and the mask bugs and reduce performance) by normally-off a BIOS flag. I for one would rather have the performance and don't need the counters for day-to-day ops.