8 ms·

Disappointed I didn't see fairly reasonable explanations around processor security bugs which impact broad system performance such as Spectre and Meltdown. Thi

by sharms 5y ago

Disappointed I didn't see fairly reasonable explanations around processor security bugs which impact broad system performance such as Spectre and Meltdown. This has a significant impact on Linux and Microsoft has even outlined that these fixes impact their performance (there have been many more security bugs identified since): https://www.microsoft.com/security/blog/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/ https://www.microsoft.com/security/blog/2018/01/09/understan...

koheripbal 5y ago
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.
Wowfunhappy 5y ago
If this is really what's making the difference... I wonder if these mitigations shouldn't be automatically enabled for home users. The chances of Spectre or Meltdown actually managing to acquire sensitive data seems incredibly low. Is that worth the very large performance impact?
- qzw 5y ago
  An incredibly low probability multiplied by ~billion+ users means somebody is going to lose something valuable sooner or later. And then the odds of MS getting sued for “not even patching a well-known vulnerability” becomes 100%.
  - Wowfunhappy 5y ago
    But that's also a billion+ users with much slower computers! So you need to compare the harm on both sides. And then MS could add a switch in Settings for anyone who is concerned. (I realize not many people would find it, but it seems important for the option to be accessible, without digging into the registry or some such.)
    - eganist 5y ago
      > But that's also a billion+ users with much slower computers! So you need to compare the harm on both sides. Far more likely Microsoft would be legally exposed due to a skipped patch than a patch that slows machines down. Intel on the other hand, that'd be more interesting. > And then MS could add a switch in Settings for anyone who is concerned. (I realize not many people would find it, but it seems important for the option to be accessible, without digging into the registry or some such.) Any such switch would just be disabled via GPOs by corporate security teams anyway, so what's the point? The entities who would most "benefit" wouldn't even be able to do it.
      - Wowfunhappy 5y ago
        To be clear, I am very explicitly thinking of home editions of Windows. No GPOs.
hateful 5y ago
That was my first thought. I remember reading an article before Spectre was patched, that it could slow down the speed by ~5%? I never checked back in on it. I have noticed that the latest update feels faster than all the other ones, but it's always hard to tell since that's the only time I really reboot the machine.
vladvasiliu 5y ago
It's very unclear to me how much of a performance hit there is for most desktop use-cases. My most recent CPU I use is a desktop i5-8500 which doesn't feel faster than my older i7-3930k aside from disk access [0], both of which are impacted by the vulnerabilities. I practically never use the i5. Until recently my daily driver was a MacBook Pro that came out in 2013, and I don't really remember a before / after change in perceived performance or responsiveness – I haven't done any scientific benchmarks, but that computer never felt slow, and still doesn't. There's also this Phoronix benchmark [1] that compares performance with and without `mitigations=off` on linux. There are some tests where there's a very big difference, but mostly, to me, it doesn't look that crazy. In the Firefox benchmarks they do say that there's a big hit, but then I probably don't read the graphs correctly, nothing looks particularly worrisome to me. --- [0] The i5 has some NVME as opposed to an older, regular SATA drive in the i7. Still, I run a lightweight Linux install on both, so drive speed is never an issue for me, everything can fit in RAM. [1] https://www.phoronix.com/scan.php?page=article&item=spectre-meltdown-2 https://www.phoronix.com/scan.php?page=article&item=spectre-...
- tehbeard 5y ago
  > I use is a desktop i5-8500 which doesn't feel faster than my older i7-3930k I mean, looking at the specs on Intel ark that's to be expected, a newer generation mid-range CPU is typically the same speed as a high tier CPU of old. Faster bus speeds, higher turbo, some newer under the hood instruction sets for SIMD, and if the datasheet is correct, for roughly half the thermal output thanks to a process shrink.
nivenkos 5y ago
You can disable the fixes: https://make-linux-fast-again.com/ https://make-linux-fast-again.com/

by sharms 5y ago

koheripbal 5y ago

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.

Wowfunhappy 5y ago

If this is really what's making the difference... I wonder if these mitigations shouldn't be automatically enabled for home users. The chances of Spectre or Meltdown actually managing to acquire sensitive data seems incredibly low. Is that worth the very large performance impact?

qzw 5y ago
An incredibly low probability multiplied by ~billion+ users means somebody is going to lose something valuable sooner or later. And then the odds of MS getting sued for “not even patching a well-known vulnerability” becomes 100%.
- Wowfunhappy 5y ago
  But that's also a billion+ users with much slower computers! So you need to compare the harm on both sides. And then MS could add a switch in Settings for anyone who is concerned. (I realize not many people would find it, but it seems important for the option to be accessible, without digging into the registry or some such.)
  - eganist 5y ago
    > But that's also a billion+ users with much slower computers! So you need to compare the harm on both sides. Far more likely Microsoft would be legally exposed due to a skipped patch than a patch that slows machines down. Intel on the other hand, that'd be more interesting. > And then MS could add a switch in Settings for anyone who is concerned. (I realize not many people would find it, but it seems important for the option to be accessible, without digging into the registry or some such.) Any such switch would just be disabled via GPOs by corporate security teams anyway, so what's the point? The entities who would most "benefit" wouldn't even be able to do it.
    - Wowfunhappy 5y ago
      To be clear, I am very explicitly thinking of home editions of Windows. No GPOs.

hateful 5y ago

That was my first thought. I remember reading an article before Spectre was patched, that it could slow down the speed by ~5%? I never checked back in on it. I have noticed that the latest update feels faster than all the other ones, but it's always hard to tell since that's the only time I really reboot the machine.

vladvasiliu 5y ago

It's very unclear to me how much of a performance hit there is for most desktop use-cases. My most recent CPU I use is a desktop i5-8500 which doesn't feel faster than my older i7-3930k aside from disk access [0], both of which are impacted by the vulnerabilities. I practically never use the i5. Until recently my daily driver was a MacBook Pro that came out in 2013, and I don't really remember a before / after change in perceived performance or responsiveness – I haven't done any scientific benchmarks, but that computer never felt slow, and still doesn't. There's also this Phoronix benchmark [1] that compares performance with and without `mitigations=off` on linux. There are some tests where there's a very big difference, but mostly, to me, it doesn't look that crazy. In the Firefox benchmarks they do say that there's a big hit, but then I probably don't read the graphs correctly, nothing looks particularly worrisome to me. --- [0] The i5 has some NVME as opposed to an older, regular SATA drive in the i7. Still, I run a lightweight Linux install on both, so drive speed is never an issue for me, everything can fit in RAM. [1] https://www.phoronix.com/scan.php?page=article&item=spectre-meltdown-2 https://www.phoronix.com/scan.php?page=article&item=spectre-...

tehbeard 5y ago
> I use is a desktop i5-8500 which doesn't feel faster than my older i7-3930k I mean, looking at the specs on Intel ark that's to be expected, a newer generation mid-range CPU is typically the same speed as a high tier CPU of old. Faster bus speeds, higher turbo, some newer under the hood instruction sets for SIMD, and if the datasheet is correct, for roughly half the thermal output thanks to a process shrink.

nivenkos 5y ago

You can disable the fixes: https://make-linux-fast-again.com/ https://make-linux-fast-again.com/