8 ms·

Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything, just two o

Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything, just two or three additional unpatched PoCs with full source code would be enough. However, unlike buffer overflow exploits, most researches on CPUs are conducted within academic institutions, doing this certainly breaches the code of conduct. Also, CPUs are the most critical components of all computers and their vulnerabilities are difficult to fix, doing this would put a lot of users under immediate risks, unlike a root exploit, which is less risky and can be fixed within a week. Doing Full Disclosure of hardware exploits that users can not fix is much more ethically problematic than software exploits. But leaving the users in the dark and allowing Intel to delay its fixes by not to exert pressure is obviously irresponsible, which is the original argument for full disclosure. So I'm not sure. Perhaps Google's Project Zero is a good model and a good compromise between resposible/full disclosure - embargo for 90 days, full disclosure later, all information becomes public after 90 days and no extension is allowed, period. For CPUs, perhaps we can use 180 days.

hghhbvv 7y ago
I wish FPGAs were fast enough because I don’t see how else this problem can be solved. Easy to issue a patch that fixes logic implemented in FOGA. Impossible to fix hardware rooted issues unless they work around it at a huge performance cost, if at all possible. Not an EE so I’m just dumping my thoughts.
- dragontamer 7y ago
  FPGAs are significantly slower and significantly more expensive than dedicated hardware. The FPGAs used for data-center usage don't even use LUTs primarily anymore, because fully configurable LUTs are too slow and too expensive to manufacture at scale. Instead, data-center sized FPGAs use "DSP Slices" primarily (yeah, LUTS exist but its mostly DSP Slices). They're very expensive (https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-A64G-PQ-G/122-2251-ND/9645682& https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-...) and require a very specific set of skills to work with.
  - monocasa 7y ago
    DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. There's nothing about LUTs that are harder to make at scale than DSP slices. LUTs are just a little bank of SRAM, and SRAM is generally the most mature cells on a process node.
    - dragontamer 7y ago
      > DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers. > There's nothing about LUTs that are harder to make at scale than DSP slices. Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a DSP Slice. Synthesize a 32-bit wallace-tree multiplier for instance, and you'll use thousands of LUTs (maybe 2000ish). However, reserve a DSP-slice for a 32-bit multiply routine, and you'll only use ONE slice. However, those multipliers on the DSP-slice could be "wasted" if you didn't need that many multipliers. Maybe your arithmetic is primarily addition and subtraction. In any case, when most people talk about "Reconfigurable FPGAs", they're talking about the LUTs which can be the building block of any logic. They aren't talking about DSP-slices, which are effectively prebuilt ALUs connected in a mesh.
      - monocasa 7y ago
        Your original post is making it sound like FPGAs are switching from LUTs to DSP slices in the general case, which is blatantly not true. Yeah, it uses less resources to use a DSP slice instead of synthesizing a multiplier, bit that's because a DSP slice is just an 18x18 MAC. It's not replacing LUTs for general logic.
        deleted 7y ago
        [deleted]
        dragontamer 7y ago
        It wasn't my intent to say that FPGAs were switching away from LUTs in general. But I expect that FPGAs of the datacenter to be more-and-more DSP-based into the future. Think of today's supercomputer problems: Deep Learning, 3d Rendering, Finite Element Analysis, Weather Modeling, nuclear research, protein folding, even high-frequency trading. What do they all have in common? They're all giant matrix-multiplication problems at their core... fundamentally built up from the multiply-and-accumulate primitive. EDIT: The only real exception is maybe EDA. I don't know too much about those algorithms involved, but IIRC it involves binary decision diagrams (https://en.wikipedia.org/wiki/Binary_decision_diagram https://en.wikipedia.org/wiki/Binary_decision_diagram). So some problems aren't matrix-multiplication based... but I dare say the majority of today's supercomputer problems involve matrix-multiplication.
- segfaultbuserr 7y ago
  One problem of FPGAs is that the absolute dependence on proprietary tools from the vendor, the hardware industry is much more closed in comparison. By using those tools, you have to agree the terms and conditions such as the following (this one is from Xilinx), > By using this software, you agree not to: [...] display the object code of the Software on any computer screen. From a security perspective, it doesn't inspire confidence, there's no ability to do an independent verification, something like doing a reproducible build with an compiler which source code is open to audit. There's no equivalence of GCC or LLVM for FPGA. Fortunately, there are some people working on it, just saw it on the homepage, although it's a long way to go... https://news.ycombinator.com/item?id=21522522 https://news.ycombinator.com/item?id=21522522 I'm not an EE, just my 0.02 USD.
  - abjKT26nO8 7y ago
    > By using this software, you agree not to: [...] display the object code of the Software on any computer screen. I.e. ... I can print it? Good.
segfaultbuserr 7y ago
My second thought - Perhaps embargo with limited length can help, but it only solves the problem of endless embargo. But the following remains unaddressed... > Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis Being PoC-oriented means that even if there is full disclosure, Intel is still going to patch PoCs in an ad-hoc manner, rather than a full fix. Also, if you have full disclosure of a potential problem without PoC, it doesn't solve the problem - Intel can choose to ignore it by not doing a careful root-cause analysis, and fix the problem if there is any.
javajosh 7y ago
The cynic in me thinks a good capitalist would try to sell the discovery to the highest bidder. In this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short on Intel stock. I imagine the payoff would be in the millions of dollars in both cases, and I doubt either scenario is even illegal.
- segfaultbuserr 7y ago
  > a good capitalist would try to sell the discovery to the highest bidder. Not all security researchers are doing it for the money, 0day markets always exist. Malicious people who wish to use the vulnerability for profit wouldn't disclose the vulnerability to begin with. So it's not a new problem. > this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short But your comment is insightful - Intel's case is unprecedented. Due to the huge impact of the vulnerabilities, the threat is not coming from the blackhat sellers or black market buyers, but Intel. Intel itself can simply pay researchers with an NDA to keep their mouths shut, while still doing nothing. The impact of the vulnerabilities is also high enough to move the stock market, allowing insider trading.
  - jefftk 7y ago
    If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading. Here's an example of Gotham City Research trying this approach and failing: https://www.thedrum.com/news/2017/09/21/criteo-counters-fraud-claims-made-infamous-short-seller-gotham-city-research https://www.thedrum.com/news/2017/09/21/criteo-counters-frau... (Not a lawyer)
    - segfaultbuserr 7y ago
      >If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading. Thanks for the information, never thought about that. On the other hand, would purchasing information about a flaw and using the information to bet the stock constitutes insider trading?
S_A_P 7y ago
Somewhat tangential point: having a single technological leader is a significant risk. Thankfully AMD is hitting its stride again and seems to be at least somewhat immune or less susceptible to this class of attack. Apples arm processors are approaching x64 performance in some cases. Imagine if Intel had squashed the competition only to find their architecture is a security risk. As it is now, it really sucks to know that yet another cpu power robbing patch is coming. As a processor monolith they could set back most operations 10 years plugging security flaws. At least I feel like I have a few replacement options. However the skeptic in me feels like it’s only a matter of time that other platforms are researched with equal scrutiny.
- jjoonathan 7y ago
  If the vulnerability pipeline is a few years deep and AMD wasn't considered a worthwhile target a few years ago, we might not want to interpret a lack of AMD vulnerabilities as evidence that they are immune.
  - whatshisface 7y ago
    AMD was always a worthy target because they sold a lot of cost-effective mid and low range CPUs to Dell and friends. They have been absent from the peak performance market for a while but that's a small fraction of computers. After all, AMD didn't go out of business, and they had to be selling a lot of CPUs.
    - SketchySeaBeast 7y ago
      But isn't that not where the worry is? Isn't it cloud computing and server spaces where the real damage can be done here?
      - tylerhou 7y ago
        No, these vulnerabilities potentially let userspace code escalate privileges, which could lead to ransomware or credential exfiltration. Stealing bank account passwords clearly does damage, and various governments have paid ransoms on the order of $100,000 to recover encrypted files. I’d argue that side-channel attacks are less of a problem in the server space because servers generally don’t download untrusted code from the internet and execute that code blindly (assuming you aren’t running other peoples’ VMs).
MaxBarraclough 7y ago
> Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything At the risk of sounding pedantic, that's not 'full disclosure', that's 'responsible disclosure' - https://en.wikipedia.org/wiki/Responsible_disclosure https://en.wikipedia.org/wiki/Responsible_disclosure
- segfaultbuserr 7y ago
  Is it? I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero is responsible disclosure because the information is released after the problem is patched. I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".
  - MaxBarraclough 7y ago
    > I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero Good point. > I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure". If you aren't disclosing everything you have, it's not full disclosure, it's some other disclosure model. I think we're just arguing semantics though, as I fully agree with your earlier paragraph, that hardware vulnerabilities are trickier than software vulnerabilities regarding disclosure, and that Project Zero is doing roughly the right thing.

hghhbvv 7y ago

I wish FPGAs were fast enough because I don’t see how else this problem can be solved. Easy to issue a patch that fixes logic implemented in FOGA. Impossible to fix hardware rooted issues unless they work around it at a huge performance cost, if at all possible. Not an EE so I’m just dumping my thoughts.

dragontamer 7y ago
FPGAs are significantly slower and significantly more expensive than dedicated hardware. The FPGAs used for data-center usage don't even use LUTs primarily anymore, because fully configurable LUTs are too slow and too expensive to manufacture at scale. Instead, data-center sized FPGAs use "DSP Slices" primarily (yeah, LUTS exist but its mostly DSP Slices). They're very expensive (https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-A64G-PQ-G/122-2251-ND/9645682& https://www.digikey.com/product-detail/en/xilinx-inc/A-U200-...) and require a very specific set of skills to work with.
- monocasa 7y ago
  DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. There's nothing about LUTs that are harder to make at scale than DSP slices. LUTs are just a little bank of SRAM, and SRAM is generally the most mature cells on a process node.
  - dragontamer 7y ago
    > DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers. > There's nothing about LUTs that are harder to make at scale than DSP slices. Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a DSP Slice. Synthesize a 32-bit wallace-tree multiplier for instance, and you'll use thousands of LUTs (maybe 2000ish). However, reserve a DSP-slice for a 32-bit multiply routine, and you'll only use ONE slice. However, those multipliers on the DSP-slice could be "wasted" if you didn't need that many multipliers. Maybe your arithmetic is primarily addition and subtraction. In any case, when most people talk about "Reconfigurable FPGAs", they're talking about the LUTs which can be the building block of any logic. They aren't talking about DSP-slices, which are effectively prebuilt ALUs connected in a mesh.
    - monocasa 7y ago
      Your original post is making it sound like FPGAs are switching from LUTs to DSP slices in the general case, which is blatantly not true. Yeah, it uses less resources to use a DSP slice instead of synthesizing a multiplier, bit that's because a DSP slice is just an 18x18 MAC. It's not replacing LUTs for general logic.
      - deleted 7y ago
        [deleted]
      - dragontamer 7y ago
        It wasn't my intent to say that FPGAs were switching away from LUTs in general. But I expect that FPGAs of the datacenter to be more-and-more DSP-based into the future. Think of today's supercomputer problems: Deep Learning, 3d Rendering, Finite Element Analysis, Weather Modeling, nuclear research, protein folding, even high-frequency trading. What do they all have in common? They're all giant matrix-multiplication problems at their core... fundamentally built up from the multiply-and-accumulate primitive. EDIT: The only real exception is maybe EDA. I don't know too much about those algorithms involved, but IIRC it involves binary decision diagrams (https://en.wikipedia.org/wiki/Binary_decision_diagram https://en.wikipedia.org/wiki/Binary_decision_diagram). So some problems aren't matrix-multiplication based... but I dare say the majority of today's supercomputer problems involve matrix-multiplication.
segfaultbuserr 7y ago
One problem of FPGAs is that the absolute dependence on proprietary tools from the vendor, the hardware industry is much more closed in comparison. By using those tools, you have to agree the terms and conditions such as the following (this one is from Xilinx), > By using this software, you agree not to: [...] display the object code of the Software on any computer screen. From a security perspective, it doesn't inspire confidence, there's no ability to do an independent verification, something like doing a reproducible build with an compiler which source code is open to audit. There's no equivalence of GCC or LLVM for FPGA. Fortunately, there are some people working on it, just saw it on the homepage, although it's a long way to go... https://news.ycombinator.com/item?id=21522522 https://news.ycombinator.com/item?id=21522522 I'm not an EE, just my 0.02 USD.
- abjKT26nO8 7y ago
  > By using this software, you agree not to: [...] display the object code of the Software on any computer screen. I.e. ... I can print it? Good.

segfaultbuserr 7y ago

My second thought - Perhaps embargo with limited length can help, but it only solves the problem of endless embargo. But the following remains unaddressed... > Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis Being PoC-oriented means that even if there is full disclosure, Intel is still going to patch PoCs in an ad-hoc manner, rather than a full fix. Also, if you have full disclosure of a potential problem without PoC, it doesn't solve the problem - Intel can choose to ignore it by not doing a careful root-cause analysis, and fix the problem if there is any.

javajosh 7y ago

The cynic in me thinks a good capitalist would try to sell the discovery to the highest bidder. In this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short on Intel stock. I imagine the payoff would be in the millions of dollars in both cases, and I doubt either scenario is even illegal.

segfaultbuserr 7y ago
> a good capitalist would try to sell the discovery to the highest bidder. Not all security researchers are doing it for the money, 0day markets always exist. Malicious people who wish to use the vulnerability for profit wouldn't disclose the vulnerability to begin with. So it's not a new problem. > this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder would be an investor in position to exploit a short-term massive short But your comment is insightful - Intel's case is unprecedented. Due to the huge impact of the vulnerabilities, the threat is not coming from the blackhat sellers or black market buyers, but Intel. Intel itself can simply pay researchers with an NDA to keep their mouths shut, while still doing nothing. The impact of the vulnerabilities is also high enough to move the stock market, allowing insider trading.
- jefftk 7y ago
  If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading. Here's an example of Gotham City Research trying this approach and failing: https://www.thedrum.com/news/2017/09/21/criteo-counters-fraud-claims-made-infamous-short-seller-gotham-city-research https://www.thedrum.com/news/2017/09/21/criteo-counters-frau... (Not a lawyer)
  - segfaultbuserr 7y ago
    >If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading. Thanks for the information, never thought about that. On the other hand, would purchasing information about a flaw and using the information to bet the stock constitutes insider trading?

S_A_P 7y ago

Somewhat tangential point: having a single technological leader is a significant risk. Thankfully AMD is hitting its stride again and seems to be at least somewhat immune or less susceptible to this class of attack. Apples arm processors are approaching x64 performance in some cases. Imagine if Intel had squashed the competition only to find their architecture is a security risk. As it is now, it really sucks to know that yet another cpu power robbing patch is coming. As a processor monolith they could set back most operations 10 years plugging security flaws. At least I feel like I have a few replacement options. However the skeptic in me feels like it’s only a matter of time that other platforms are researched with equal scrutiny.

jjoonathan 7y ago
If the vulnerability pipeline is a few years deep and AMD wasn't considered a worthwhile target a few years ago, we might not want to interpret a lack of AMD vulnerabilities as evidence that they are immune.
- whatshisface 7y ago
  AMD was always a worthy target because they sold a lot of cost-effective mid and low range CPUs to Dell and friends. They have been absent from the peak performance market for a while but that's a small fraction of computers. After all, AMD didn't go out of business, and they had to be selling a lot of CPUs.
  - SketchySeaBeast 7y ago
    But isn't that not where the worry is? Isn't it cloud computing and server spaces where the real damage can be done here?
    - tylerhou 7y ago
      No, these vulnerabilities potentially let userspace code escalate privileges, which could lead to ransomware or credential exfiltration. Stealing bank account passwords clearly does damage, and various governments have paid ransoms on the order of $100,000 to recover encrypted files. I’d argue that side-channel attacks are less of a problem in the server space because servers generally don’t download untrusted code from the internet and execute that code blindly (assuming you aren’t running other peoples’ VMs).

MaxBarraclough 7y ago

> Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything At the risk of sounding pedantic, that's not 'full disclosure', that's 'responsible disclosure' - https://en.wikipedia.org/wiki/Responsible_disclosure https://en.wikipedia.org/wiki/Responsible_disclosure

segfaultbuserr 7y ago
Is it? I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero is responsible disclosure because the information is released after the problem is patched. I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".
- MaxBarraclough 7y ago
  > I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero Good point. > I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure". If you aren't disclosing everything you have, it's not full disclosure, it's some other disclosure model. I think we're just arguing semantics though, as I fully agree with your earlier paragraph, that hardware vulnerabilities are trickier than software vulnerabilities regarding disclosure, and that Project Zero is doing roughly the right thing.