4 ms·

> Pretty cool business model where putting dangerous vulns in your product can help you capture 90% of the market. This is extremely disingenuous phrasing. Yo

> 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...
    - tntn 7y ago
      That paper primarily discusses a (cooperative) covert channel between processes using the FPU TS register, then mentions that caches or the TLB could similarly be used to implement a covert channel. IMO, meltdown and Spectre and MDS are a different class of vulnerability, so I don't know that I would say that paper was about "such vulnerabilities."
    - Spooky23 7y ago
      The product being designed in 1995 was very different from today. Many of these trade offs result in much lower risk vulnerabilities in 1995 when you don’t have virtualization or hardware shared with anyone with a credit card. I lack the technical expertise to honestly critique the architecture. My assumption is that the folks behind the design of some of the more advanced technology on the planet aren’t morons or seeking to defraud the market. All of the noise here is about significant vulnerabilities that haven’t been exploited in public. It is a serious defect, but not the end of the world.
    - strictnein 7y ago
      That linked study covers speculative execution and hyperthreading? It seems to be covering 386/486 era processors
myself248 7y ago
At some point, I bet someone in a design meeting said "Hey, I think this might compromise security, can we study that before implementing it?" And the decision to implement it without that study, or despite it, was made. Because implementing it increased performance which made the numbers which captured market share. It's not like the processor designed itself that way. Humans made choices along the way, and every choice is a tradeoff. Execution-time attacks and other sidechannel leakage have been well-known for years, and I can't imagine that at a place like Intel, nobody had heard of that.
- gary__ 7y ago
  "At some point, I bet someone in a design meeting said "Hey, I think this might compromise security, can we study that before implementing it?" And the decision to implement it without that study, or despite it, was made." Because we should assume all your past missteps were due to willful negligence? Yeah, let's not just start making shit up to support the group think outrage.
  - dgoldstein0 7y ago
    agree, I really doubt people were like "let's compromise security for performance". More likely it was something like: "hey here's an idea for how we can get more performance" "convince me it's correct" "oh, that's cause X, Y, Z..." and either no one thought about the security implications, or no one could come up with a security problem at design time - likely just no one thought about side channel problems.
- dfrage 7y ago
  > Because implementing it increased performance which made the numbers which captured market share. More than the following big things, in both directions? - A consistent fabrication advantage until very recently? That's said to have wiped out a generation of clever hardware architects, when Intel beat their best efforts with their next process node. - Falling behind AMD with the Netburst "marchitecture", the front side bus memory bottleneck, and only supporting Itanium as a 64 bit architecture? - Reversing the above by licencing AMD64, reverting to the same Pentium Pro style design AMD was using, and copying their ccNUMA multi-chip layout (each is directly attached to memory, with fast connections between them). - AMD losing the plot after the K8 microarchitecture, including putting a huge amount of capital into buying ATI instead of pushing their CPU advantage? And then having to sell off their fabs, putting them at a permanent disadvantage until Intel's "10nm" failed? (And what happened to the K9??) - Anticompetitive marketing and sales? > Execution-time attacks and other sidechannel leakage have been well-known for years, and I can't imagine that at a place like Intel, nobody had heard of that. The strange thing is that security researchers assumed for years that Intel was accounting for this, when it turned out not a single one of AMD, ARM, IBM POWER and mainframe/Z, Intel, MIPS, or SPARC did?

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...
  - tntn 7y ago
    That paper primarily discusses a (cooperative) covert channel between processes using the FPU TS register, then mentions that caches or the TLB could similarly be used to implement a covert channel. IMO, meltdown and Spectre and MDS are a different class of vulnerability, so I don't know that I would say that paper was about "such vulnerabilities."
  - Spooky23 7y ago
    The product being designed in 1995 was very different from today. Many of these trade offs result in much lower risk vulnerabilities in 1995 when you don’t have virtualization or hardware shared with anyone with a credit card. I lack the technical expertise to honestly critique the architecture. My assumption is that the folks behind the design of some of the more advanced technology on the planet aren’t morons or seeking to defraud the market. All of the noise here is about significant vulnerabilities that haven’t been exploited in public. It is a serious defect, but not the end of the world.
  - strictnein 7y ago
    That linked study covers speculative execution and hyperthreading? It seems to be covering 386/486 era processors

myself248 7y ago

At some point, I bet someone in a design meeting said "Hey, I think this might compromise security, can we study that before implementing it?" And the decision to implement it without that study, or despite it, was made. Because implementing it increased performance which made the numbers which captured market share. It's not like the processor designed itself that way. Humans made choices along the way, and every choice is a tradeoff. Execution-time attacks and other sidechannel leakage have been well-known for years, and I can't imagine that at a place like Intel, nobody had heard of that.

gary__ 7y ago
"At some point, I bet someone in a design meeting said "Hey, I think this might compromise security, can we study that before implementing it?" And the decision to implement it without that study, or despite it, was made." Because we should assume all your past missteps were due to willful negligence? Yeah, let's not just start making shit up to support the group think outrage.
- dgoldstein0 7y ago
  agree, I really doubt people were like "let's compromise security for performance". More likely it was something like: "hey here's an idea for how we can get more performance" "convince me it's correct" "oh, that's cause X, Y, Z..." and either no one thought about the security implications, or no one could come up with a security problem at design time - likely just no one thought about side channel problems.
dfrage 7y ago
> Because implementing it increased performance which made the numbers which captured market share. More than the following big things, in both directions? - A consistent fabrication advantage until very recently? That's said to have wiped out a generation of clever hardware architects, when Intel beat their best efforts with their next process node. - Falling behind AMD with the Netburst "marchitecture", the front side bus memory bottleneck, and only supporting Itanium as a 64 bit architecture? - Reversing the above by licencing AMD64, reverting to the same Pentium Pro style design AMD was using, and copying their ccNUMA multi-chip layout (each is directly attached to memory, with fast connections between them). - AMD losing the plot after the K8 microarchitecture, including putting a huge amount of capital into buying ATI instead of pushing their CPU advantage? And then having to sell off their fabs, putting them at a permanent disadvantage until Intel's "10nm" failed? (And what happened to the K9??) - Anticompetitive marketing and sales? > Execution-time attacks and other sidechannel leakage have been well-known for years, and I can't imagine that at a place like Intel, nobody had heard of that. The strange thing is that security researchers assumed for years that Intel was accounting for this, when it turned out not a single one of AMD, ARM, IBM POWER and mainframe/Z, Intel, MIPS, or SPARC did?