6 ms·

An alternative interpretation is that there are no current "performance hits", just the legitimate performance is now (better) known. Those former "performance

by 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
    - johncolanduoni 5y ago
      Or simply none of them were aware that the kinds of speculation they were doing were capable of producing exploitable vulnerabilities. It took security researchers a long time to find these issues, and the kind of speculation that the original Spectre and Meltdown exploited were well known outside of the chipmakers for over a decade. Intel was simply more aggressive at that particular avenue of performance improvement.
motardo 5y ago
For the record, it was Volkswagen that cheated the emissions test, not Volvo
- zargon 5y ago
  Thanks! I wasn't sure I remembered correctly but didn't immediately see the answer in a quick google.
  - nitrogen 5y ago
    didn't immediately see the answer in a quick google. Whether happening organically or through the magic of reputation management, that's pretty alarming, actually. Give it another few years and nobody will even remember.
    - toomanybeersies 5y ago
      If GP searched for something along the lines of "Volvo emissions cheating", then I hardly think it's alarming that the VW scandal didn't come up.
      - pope_meat 5y ago
        Just searched "emissions cheating" and uh, is like, every auto maker cheating on emissions? I remember the VW scandal, but this quick search leaves me to conclude that VW is only the most memorable one that got mass media attention of late. But hey, we love our corporate overlords, they only want what's best for us, the shareholders. (Not actually a shareholder of anything)
        paganel 5y ago
        > Just searched "emissions cheating" and uh, is like, every auto maker cheating on emissions? More or less, yes, they all did. As an European I'd say it's a shared blame, though, as in the officials around Europe (both at national and at the EU level) who had very strongly pushed for diesel for the previous two to three decades (mostly through taxation/pricing policies) also deserve a very big part of this blame. The Americans got it right (especially states like California) when relegating diesel to mostly commercial/truck/public transport use, but the hybris and the "we know better than the silly Americans when it comes to the environment" prevailed in the end, that's why it took Dieselgate and at least a couple of decades for those officials to reverse their past mistakes.
chii 5y ago
> former "performance gains" were cheated why would cache performance be considered a cheat?
- danielheath 5y ago
  Because it makes several of the isolation features the processor ships with useless, without documenting it?
  - jcelerier 5y ago
    But isolation had never been sold as a security feature, only as a "user-space crash can't bring down the kernel", no ?
    - nix23 5y ago
      Isolation (Rings) was first implemented in Multics (first in software, then in hardware..a bit like today (user-mode and kernel/hypervisor mode)), foremost for security second for stability.
    - msbarnett 5y ago
      No. Isolation has always been a security feature, not a reliability feature. Consider that local privilege escalations are generally (and I'd say correctly) treated as critical severity issues. Any general purpose process memory read-isolation leak is a quick route to a local privilege escalation, so how could isolation be anything other than a security feature? In its absence, you might as well run everything as root and there would be no point whatsoever to caring about privilege escalations.
      - jcelerier 5y ago
        > Consider that local privilege escalations are generally (and I'd say correctly) treated as critical severity issues. Any general purpose process memory read-isolation leak is a quick route to a local privilege escalation, so how could isolation be anything other than a security feature? https://xkcd.com/1200/ https://xkcd.com/1200/ > In its absence, you might as well run everything as root this is what 99% of people with a home computer did until windows XP (and even then most people today run under an admin account of some sorts on their computers) isolation between users is only relevant for clusters, it's a super minority usecase versus what is the main thing that matters, home computers which only have one human user anyways. But I guess you'd disagree with Stallman's paragraph at the end here: https://ftp.gnu.org/old-gnu/Manuals/coreutils-4.5.4/html_node/coreutils_149.html https://ftp.gnu.org/old-gnu/Manuals/coreutils-4.5.4/html_nod...

by zargon 5y ago

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
  - johncolanduoni 5y ago
    Or simply none of them were aware that the kinds of speculation they were doing were capable of producing exploitable vulnerabilities. It took security researchers a long time to find these issues, and the kind of speculation that the original Spectre and Meltdown exploited were well known outside of the chipmakers for over a decade. Intel was simply more aggressive at that particular avenue of performance improvement.

motardo 5y ago

For the record, it was Volkswagen that cheated the emissions test, not Volvo

zargon 5y ago
Thanks! I wasn't sure I remembered correctly but didn't immediately see the answer in a quick google.
- nitrogen 5y ago
  didn't immediately see the answer in a quick google. Whether happening organically or through the magic of reputation management, that's pretty alarming, actually. Give it another few years and nobody will even remember.
  - toomanybeersies 5y ago
    If GP searched for something along the lines of "Volvo emissions cheating", then I hardly think it's alarming that the VW scandal didn't come up.
    - pope_meat 5y ago
      Just searched "emissions cheating" and uh, is like, every auto maker cheating on emissions? I remember the VW scandal, but this quick search leaves me to conclude that VW is only the most memorable one that got mass media attention of late. But hey, we love our corporate overlords, they only want what's best for us, the shareholders. (Not actually a shareholder of anything)
      - paganel 5y ago
        > Just searched "emissions cheating" and uh, is like, every auto maker cheating on emissions? More or less, yes, they all did. As an European I'd say it's a shared blame, though, as in the officials around Europe (both at national and at the EU level) who had very strongly pushed for diesel for the previous two to three decades (mostly through taxation/pricing policies) also deserve a very big part of this blame. The Americans got it right (especially states like California) when relegating diesel to mostly commercial/truck/public transport use, but the hybris and the "we know better than the silly Americans when it comes to the environment" prevailed in the end, that's why it took Dieselgate and at least a couple of decades for those officials to reverse their past mistakes.

chii 5y ago

> former "performance gains" were cheated why would cache performance be considered a cheat?

danielheath 5y ago
Because it makes several of the isolation features the processor ships with useless, without documenting it?
- jcelerier 5y ago
  But isolation had never been sold as a security feature, only as a "user-space crash can't bring down the kernel", no ?
  - nix23 5y ago
    Isolation (Rings) was first implemented in Multics (first in software, then in hardware..a bit like today (user-mode and kernel/hypervisor mode)), foremost for security second for stability.
  - msbarnett 5y ago
    No. Isolation has always been a security feature, not a reliability feature. Consider that local privilege escalations are generally (and I'd say correctly) treated as critical severity issues. Any general purpose process memory read-isolation leak is a quick route to a local privilege escalation, so how could isolation be anything other than a security feature? In its absence, you might as well run everything as root and there would be no point whatsoever to caring about privilege escalations.
    - jcelerier 5y ago
      > Consider that local privilege escalations are generally (and I'd say correctly) treated as critical severity issues. Any general purpose process memory read-isolation leak is a quick route to a local privilege escalation, so how could isolation be anything other than a security feature? https://xkcd.com/1200/ https://xkcd.com/1200/ > In its absence, you might as well run everything as root this is what 99% of people with a home computer did until windows XP (and even then most people today run under an admin account of some sorts on their computers) isolation between users is only relevant for clusters, it's a super minority usecase versus what is the main thing that matters, home computers which only have one human user anyways. But I guess you'd disagree with Stallman's paragraph at the end here: https://ftp.gnu.org/old-gnu/Manuals/coreutils-4.5.4/html_node/coreutils_149.html https://ftp.gnu.org/old-gnu/Manuals/coreutils-4.5.4/html_nod...