6 ms·

Pretty cool business model where putting dangerous vulns in your product can help you capture 90% of the market. Then when your fuckups are discovered, other p

Pretty cool business model where putting dangerous vulns in your product can help you capture 90% of the market. Then when your fuckups are discovered, other people not on your payroll expend their own resources to fix it. And you don't even have to compensate customers who paid full price but now find 40% of their compute evaporated. And that massive performance hit needed to fix your fuckups stimulates incremental demand for your product because customers now need more cores to finish their compute.

simonsays2 7y ago
At least as upstanding as sending your shills to bad mouth American products.
molticrystal 7y ago
>Unlike previous speculative execution flaws that partially affected AMD and Arm-based processors, the MDS flaws are exclusive to Intel chips. This isn't an excuse for Intel and how they (sometimes poorly) handle issues that come up. And it is well known that many of these vulnerabilities are currently specific to Intel and how their subsystems are implemented, or only exist on Intel processors. But side-channel attacks are a nearly universal vulnerability. SMT of which Hyper-Threading is an implementation of is used in many chips from many companies, AMD's Bulldozer, IBM's POWER, Sun/Oracle's Sparc, etc. These exploits are not a monolithic process, but many techniques chained together to get most of these exploits to work, and this common knowledgebase which has been refined by the researches will most certainly be recycled and reused on other processors. If anything, the "capture 90% of the market." by Intel as you put it only ensures that these problems will usually be discovered on their processor's first. If as much effort was put towards other cpus as it is towards Intel, you would see significant performance hits as well with them.
- dfrage 7y ago
  Expanding on your points, only AMD, SPARC and MIPS avoided Meltdown bugs, they were also found in ARM, and IBM POWER and mainframe/Z designs. All of these vendors have out-of-order speculative execution designs that are vulnerable to Spectre. > If anything, the "capture 90% of the market." by Intel as you put it only ensures that these problems will usually be discovered on their processor's first. Precisely. I haven't looked at the MDS set of flaws yet, but to take the first version of Foreshadow/L1TF, it targets the Intel SGX enclave, by definition the designs of other companies that don't have SGX won't be vulnerable. But as you note this doesn't mean they don't have their own design or implementation specific bugs.
  - jdietrich 7y ago
    Intel played fast-and-loose with correctness to eke out performance gains. They cut corners that they shouldn't have cut and now their customers are paying the price. Other companies cut similar corners, but Intel did it on a gratuitous scale.
    - chx 7y ago
      You have zero proof to that and your explanation also violates Hanlon's razor (Never attribute to malice that which is adequately explained by stupidity.)
      - atq2119 7y ago
        I don't think it was malice, but I think it is perfectly fair to say Intel was playing fast and loose here, and they deserve all the flak they're getting as a consequence. Vulnerabilities like Meltdown and the latest "MDS" vulnerabilities are absolutely a design decision. Think about Meltdown, for example. The problem here was that data from the L1$ memory was forwarded to subsequent instructions during speculative execution even when privilege / permission checks failed. Now the way that an L1$ has to be designed, the TLB lookup happens before reading data from L1$ memory (because you need to know the physical address in order to determine whether there was a cache hit and if so, which line of L1$ to read), and the TLB lookup gives you all the permission bits required to do the permission check. Now you have a choice about what to do when the permission check fails. Either you read the L1$ memory anyway, forward the fact that the permissions check failed separately and rely on later logic to trigger an exception when the instruction would retire. This is clearly what Intel did. Or you can treat this situation more like a cache miss, don't read from L1$ and don't execute subsequent instructions. This seems to be what AMD have done and while it may be slightly more costly (why?), it can't be that much more expensive because you have to track the exception status either way. The point is, at some place in the design a conscious choice was made to allow instructions to continue executing even though a permissions check has failed. The MDS flaws seem similar, though it's a bit harder to judge what exactly was going on there since it's even deeper in microarchitectural details.
BubRoss 7y ago
That's all in retrospect - Intel hasn't even really dropped their prices or increased their core counts from AMD competition or security disasters.
- Narishma 7y ago
  Why would they? They keep selling all the chips they can make at their current prices.
McGlockenshire 7y ago
> Pretty cool business model where putting dangerous vulns in your product can help you capture 90% of the market. This is extremely disingenuous phrasing. You seem to be trying to craft a narrative that makes putting security vulnerabilities in products an intentional thing to sabotage people, time, and resources.
- panarky 7y ago
  Of course it's not "an intentional thing to sabotage people, time, and resources". It's intentional business decision to maximize performance and minimize costs paid by Intel, making their products faster and generating higher margins. They achieved this by gambling that vulns wouldn't be exploitable. But Intel externalized that risk onto their customers and partners without their knowledge or consent. So when the gamble failed, the rest of the ecosystem bears the cost while Intel harvests the gains for themselves. Externalizing risks and losses on others without their knowledge or consent is a form of theft.
  - strictnein 7y ago
    > They achieved this by gambling that vulns wouldn't be exploitable. That's a huge leap, and seemingly without merit. You're still just arguing that Intel knew this would create huge vulns and they went ahead regardless, which is baseless.
    - tntn 7y ago
      Right, I think it makes a lot of sense that the engineers designing the cores didn't think about the security implications. I know I wouldn't have.
      - deleted 7y ago
        [deleted]
    - usr1106 7y ago
      > You're still just arguing that Intel knew this would create huge vulns and they went ahead regardless, which is baseless. The first scientific paper about such vulnerabilities namely in Intel processors is from 1995 [1]. They went ahead regardless. Processor technology has developed a lot. Many things that were not practically feasible in 1995 are possible today. That holds for the good and the bad. There must be some people inside Intel who must have understood that. Otherwise all that progress would not have possible. Some experts might have blind spots, but I doubt Intel microarchitecture is developed by just a handful of people. [1] https://en.m.wikipedia.org/wiki/Meltdown_(security_vulnerability) https://en.m.wikipedia.org/wiki/Meltdown_(security_vulnerabi...
amelius 7y ago
That would only be valid as a short-term strategy.
- dfrage 7y ago
  And for Intel these bugs go back to the first Pentium Pro in 1995, their first out-of-order speculative execution design. Very cunning of them, along with IBM two years earlier, the SPARC bunch starting that year, MIPS and AMD a year later, and recently ARM as it targeted higher performance to follow the same exactly "strategy". Or maybe it was an industry blind spot, now a very big deal because so many of these CPUs run other people's random code, JavaScript in browsers, and anything and everything in shared cloud hosts.
  - Paianni 7y ago
    I don't know about Fujitsu but Sun's SPARC designs were free from speculative execution until Oracle bought them.
    - dfrage 7y ago
      Or did no one bother to check the older designs??
      - dfrage 7y ago
        Oops, didn't read your comment closely enough, strike my above comment. Followed the Wikipedia link to the 1995 Fujitsu/HAL out-of-order design (https://en.wikipedia.org/wiki/HAL_SPARC64 https://en.wikipedia.org/wiki/HAL_SPARC64) and it says it's superscalar, but then that the first version can execute as many as 4 instructions at once and out-of-order. And from the very first version had branch prediction, which equals speculative execution as far as I know.
  - BlueTemplar 7y ago
    Prophetic words : https://www.youtube.com/watch?v=qpMvS1Q1sos https://www.youtube.com/watch?v=qpMvS1Q1sos
tntn 7y ago
And how about the generations of computer architecture professors that have promulgated the lie that is "architecturally visible state," am I right? Speculative execution is fine, cause we just throw away the results before they become architecturally visible. Those professors aren't doing too bad now either, with plenty of papers to be published outlining the flaws and proposing solutions. /s Really, though, humanity is still pretty new to this whole computer architecture thing in general, and running untrusted code securely in particular. Im skeptical that someone at Intel was aware for the possibility of vulnerabilities for 10+ years before any of them were made public. To be honest, I'm a little perplexed by the animosity directed towards Intel after all these vulnerabilities. Vulnerabilities in software are most frequently the result of ignorance, but everyone seems to assume the engineers and managers at Intel knew better (or should have know better). Who would have told them?
- throwaway2048 7y ago
  It was known since the Pentium 4 era that hyper-threading had serious timing attack concerns, concerns Intel seems to have completely ignored. http://www.daemonology.net/hyperthreading-considered-harmful/ http://www.daemonology.net/hyperthreading-considered-harmful...
  - tntn 7y ago
    Linux ignored those concerns as well. Torvalds didn't think hyperthreading was at fault, and Kleen stated that it was a "user space problem." In other words, there wasn't exactly consensus that there was something to fix. Anyway, that's not the same vulnerability as any of those that have become public in the last 18 months.
    - throwaway2048 7y ago
      Its very much in the same class of vulnerabilities, arguably its completely impossible to secure SMT, because it leaks information about what other threads are doing by the very virtue of how it works (using CPU resources the other thread isn't utilizing in a very fine grained clock-for-clock way)
Spooky23 7y ago
Who are these customers? In my case, we observed very marginal performance impacts from last year’s mitigations.
teddyh 7y ago
“Put more bugs in the software! I’m making a fortune out here!” https://dilbert.com/strip/2000-03-19 https://dilbert.com/strip/2000-03-19

simonsays2 7y ago

At least as upstanding as sending your shills to bad mouth American products.

molticrystal 7y ago

>Unlike previous speculative execution flaws that partially affected AMD and Arm-based processors, the MDS flaws are exclusive to Intel chips. This isn't an excuse for Intel and how they (sometimes poorly) handle issues that come up. And it is well known that many of these vulnerabilities are currently specific to Intel and how their subsystems are implemented, or only exist on Intel processors. But side-channel attacks are a nearly universal vulnerability. SMT of which Hyper-Threading is an implementation of is used in many chips from many companies, AMD's Bulldozer, IBM's POWER, Sun/Oracle's Sparc, etc. These exploits are not a monolithic process, but many techniques chained together to get most of these exploits to work, and this common knowledgebase which has been refined by the researches will most certainly be recycled and reused on other processors. If anything, the "capture 90% of the market." by Intel as you put it only ensures that these problems will usually be discovered on their processor's first. If as much effort was put towards other cpus as it is towards Intel, you would see significant performance hits as well with them.

dfrage 7y ago
Expanding on your points, only AMD, SPARC and MIPS avoided Meltdown bugs, they were also found in ARM, and IBM POWER and mainframe/Z designs. All of these vendors have out-of-order speculative execution designs that are vulnerable to Spectre. > If anything, the "capture 90% of the market." by Intel as you put it only ensures that these problems will usually be discovered on their processor's first. Precisely. I haven't looked at the MDS set of flaws yet, but to take the first version of Foreshadow/L1TF, it targets the Intel SGX enclave, by definition the designs of other companies that don't have SGX won't be vulnerable. But as you note this doesn't mean they don't have their own design or implementation specific bugs.
- jdietrich 7y ago
  Intel played fast-and-loose with correctness to eke out performance gains. They cut corners that they shouldn't have cut and now their customers are paying the price. Other companies cut similar corners, but Intel did it on a gratuitous scale.
  - chx 7y ago
    You have zero proof to that and your explanation also violates Hanlon's razor (Never attribute to malice that which is adequately explained by stupidity.)
    - atq2119 7y ago
      I don't think it was malice, but I think it is perfectly fair to say Intel was playing fast and loose here, and they deserve all the flak they're getting as a consequence. Vulnerabilities like Meltdown and the latest "MDS" vulnerabilities are absolutely a design decision. Think about Meltdown, for example. The problem here was that data from the L1$ memory was forwarded to subsequent instructions during speculative execution even when privilege / permission checks failed. Now the way that an L1$ has to be designed, the TLB lookup happens before reading data from L1$ memory (because you need to know the physical address in order to determine whether there was a cache hit and if so, which line of L1$ to read), and the TLB lookup gives you all the permission bits required to do the permission check. Now you have a choice about what to do when the permission check fails. Either you read the L1$ memory anyway, forward the fact that the permissions check failed separately and rely on later logic to trigger an exception when the instruction would retire. This is clearly what Intel did. Or you can treat this situation more like a cache miss, don't read from L1$ and don't execute subsequent instructions. This seems to be what AMD have done and while it may be slightly more costly (why?), it can't be that much more expensive because you have to track the exception status either way. The point is, at some place in the design a conscious choice was made to allow instructions to continue executing even though a permissions check has failed. The MDS flaws seem similar, though it's a bit harder to judge what exactly was going on there since it's even deeper in microarchitectural details.

BubRoss 7y ago

That's all in retrospect - Intel hasn't even really dropped their prices or increased their core counts from AMD competition or security disasters.

Narishma 7y ago
Why would they? They keep selling all the chips they can make at their current prices.

McGlockenshire 7y ago

> Pretty cool business model where putting dangerous vulns in your product can help you capture 90% of the market. This is extremely disingenuous phrasing. You seem to be trying to craft a narrative that makes putting security vulnerabilities in products an intentional thing to sabotage people, time, and resources.

panarky 7y ago
Of course it's not "an intentional thing to sabotage people, time, and resources". It's intentional business decision to maximize performance and minimize costs paid by Intel, making their products faster and generating higher margins. They achieved this by gambling that vulns wouldn't be exploitable. But Intel externalized that risk onto their customers and partners without their knowledge or consent. So when the gamble failed, the rest of the ecosystem bears the cost while Intel harvests the gains for themselves. Externalizing risks and losses on others without their knowledge or consent is a form of theft.
- strictnein 7y ago
  > They achieved this by gambling that vulns wouldn't be exploitable. That's a huge leap, and seemingly without merit. You're still just arguing that Intel knew this would create huge vulns and they went ahead regardless, which is baseless.
  - tntn 7y ago
    Right, I think it makes a lot of sense that the engineers designing the cores didn't think about the security implications. I know I wouldn't have.
    - deleted 7y ago
      [deleted]
  - usr1106 7y ago
    > You're still just arguing that Intel knew this would create huge vulns and they went ahead regardless, which is baseless. The first scientific paper about such vulnerabilities namely in Intel processors is from 1995 [1]. They went ahead regardless. Processor technology has developed a lot. Many things that were not practically feasible in 1995 are possible today. That holds for the good and the bad. There must be some people inside Intel who must have understood that. Otherwise all that progress would not have possible. Some experts might have blind spots, but I doubt Intel microarchitecture is developed by just a handful of people. [1] https://en.m.wikipedia.org/wiki/Meltdown_(security_vulnerability) https://en.m.wikipedia.org/wiki/Meltdown_(security_vulnerabi...

amelius 7y ago

That would only be valid as a short-term strategy.

dfrage 7y ago
And for Intel these bugs go back to the first Pentium Pro in 1995, their first out-of-order speculative execution design. Very cunning of them, along with IBM two years earlier, the SPARC bunch starting that year, MIPS and AMD a year later, and recently ARM as it targeted higher performance to follow the same exactly "strategy". Or maybe it was an industry blind spot, now a very big deal because so many of these CPUs run other people's random code, JavaScript in browsers, and anything and everything in shared cloud hosts.
- Paianni 7y ago
  I don't know about Fujitsu but Sun's SPARC designs were free from speculative execution until Oracle bought them.
  - dfrage 7y ago
    Or did no one bother to check the older designs??
    - dfrage 7y ago
      Oops, didn't read your comment closely enough, strike my above comment. Followed the Wikipedia link to the 1995 Fujitsu/HAL out-of-order design (https://en.wikipedia.org/wiki/HAL_SPARC64 https://en.wikipedia.org/wiki/HAL_SPARC64) and it says it's superscalar, but then that the first version can execute as many as 4 instructions at once and out-of-order. And from the very first version had branch prediction, which equals speculative execution as far as I know.
- BlueTemplar 7y ago
  Prophetic words : https://www.youtube.com/watch?v=qpMvS1Q1sos https://www.youtube.com/watch?v=qpMvS1Q1sos

tntn 7y ago

And how about the generations of computer architecture professors that have promulgated the lie that is "architecturally visible state," am I right? Speculative execution is fine, cause we just throw away the results before they become architecturally visible. Those professors aren't doing too bad now either, with plenty of papers to be published outlining the flaws and proposing solutions. /s Really, though, humanity is still pretty new to this whole computer architecture thing in general, and running untrusted code securely in particular. Im skeptical that someone at Intel was aware for the possibility of vulnerabilities for 10+ years before any of them were made public. To be honest, I'm a little perplexed by the animosity directed towards Intel after all these vulnerabilities. Vulnerabilities in software are most frequently the result of ignorance, but everyone seems to assume the engineers and managers at Intel knew better (or should have know better). Who would have told them?

throwaway2048 7y ago
It was known since the Pentium 4 era that hyper-threading had serious timing attack concerns, concerns Intel seems to have completely ignored. http://www.daemonology.net/hyperthreading-considered-harmful/ http://www.daemonology.net/hyperthreading-considered-harmful...
- tntn 7y ago
  Linux ignored those concerns as well. Torvalds didn't think hyperthreading was at fault, and Kleen stated that it was a "user space problem." In other words, there wasn't exactly consensus that there was something to fix. Anyway, that's not the same vulnerability as any of those that have become public in the last 18 months.
  - throwaway2048 7y ago
    Its very much in the same class of vulnerabilities, arguably its completely impossible to secure SMT, because it leaks information about what other threads are doing by the very virtue of how it works (using CPU resources the other thread isn't utilizing in a very fine grained clock-for-clock way)

Spooky23 7y ago

Who are these customers? In my case, we observed very marginal performance impacts from last year’s mitigations.

teddyh 7y ago

“Put more bugs in the software! I’m making a fortune out here!” https://dilbert.com/strip/2000-03-19 https://dilbert.com/strip/2000-03-19