8 ms·

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis,

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, leaving the public with a false sense of security. Slapping a year-long embargo after another (many news cycles apart) and keeping vulnerabilities (too) many people are aware of from the public for a long time is still a viable strategy. This is troubling.

spookydookeedoo 7y ago
The Deep State works in mysterious ways in plain sight. Freedom is an illusion. ;-)
mtgx 7y ago
It certainly is, and that much was obvious as Intel "committed" to fixing Spectre V1 in software as opposed to hardware. Worse yet, it doesn't think a hardware solution is necessary. Except, that pretty much all recent Spectre-related bugs are variants of Spectre V1.
- bonzini 7y ago
  They are not. They are based on leaking microarchitectural state such as the contents of the store buffer, while spectrev1 is based on leaks from the branch predictor. The difference is that the contents of e.g. the store buffer are short-lived, while branch prediction is by design learning behavior of the program for long term use. It's not a coincidence that Spectre v1 affected all processors and not just Intel x86. Also Spectre v1 still has no widely-deployed hardware mitigation, while for all other vulnerabilities the processor could be patched to add a "flush the leaked state" instruction with a microcode update.
Mirioron 7y ago
I wonder if it might not come to bite them though. Doing it this way means that the media will constantly keep talking about yet another vulnerability in Intel CPUs for years. There's a chance that Intel might and up picking a reputation like Flash did for being insecure.
- reacweb 7y ago
  Or like java applet. Oracle has killed java applet by not handling security issues in a responsible manner.
  - yrro 7y ago
    To be fair the entire approach was flawed and should have been abandoned in favour of SELinux plus something like seccomp years before.
    - zzzcpan 7y ago
      Selinux, apparmor, etc. are not viable security solutions for pretty much anything, because they are too coarse grained. Seccomp that blocks everything, but leaves just a couple of syscalls to interact with an external proxy process is closer to what could have worked, which is basically a sandbox.
      - cyberpunk 7y ago
        How do you feel about openbsd's pledge()? I would really like something as simple as that on linux...
        mmis1000 7y ago
        seccomp actually has that ability to allow only small portion of selective operations. Block everything except io is just one of its blocking mode. And the list is even configurable. Docker do use such ability to filter out sys-calls that shouldn't be used in the container.
segfaultbuserr 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, 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.
simion314 7y ago
Delaying the fixes is probably making them more money, if they lose a few more percent of performance they lose the number one position on all possible use cases/workflows , the PR hit will be huge, people could demand refunds or compensation (I mean you just sold them an expensive product without disclosing it is insecure and it will lose it's performance)
deleted 7y ago
[deleted]
josteink 7y ago
> This is troubling. Only for people who for whatever reason still continue to buy Intel-based systems.

spookydookeedoo 7y ago

The Deep State works in mysterious ways in plain sight. Freedom is an illusion. ;-)

mtgx 7y ago

It certainly is, and that much was obvious as Intel "committed" to fixing Spectre V1 in software as opposed to hardware. Worse yet, it doesn't think a hardware solution is necessary. Except, that pretty much all recent Spectre-related bugs are variants of Spectre V1.

bonzini 7y ago
They are not. They are based on leaking microarchitectural state such as the contents of the store buffer, while spectrev1 is based on leaks from the branch predictor. The difference is that the contents of e.g. the store buffer are short-lived, while branch prediction is by design learning behavior of the program for long term use. It's not a coincidence that Spectre v1 affected all processors and not just Intel x86. Also Spectre v1 still has no widely-deployed hardware mitigation, while for all other vulnerabilities the processor could be patched to add a "flush the leaked state" instruction with a microcode update.

Mirioron 7y ago

I wonder if it might not come to bite them though. Doing it this way means that the media will constantly keep talking about yet another vulnerability in Intel CPUs for years. There's a chance that Intel might and up picking a reputation like Flash did for being insecure.

reacweb 7y ago
Or like java applet. Oracle has killed java applet by not handling security issues in a responsible manner.
- yrro 7y ago
  To be fair the entire approach was flawed and should have been abandoned in favour of SELinux plus something like seccomp years before.
  - zzzcpan 7y ago
    Selinux, apparmor, etc. are not viable security solutions for pretty much anything, because they are too coarse grained. Seccomp that blocks everything, but leaves just a couple of syscalls to interact with an external proxy process is closer to what could have worked, which is basically a sandbox.
    - cyberpunk 7y ago
      How do you feel about openbsd's pledge()? I would really like something as simple as that on linux...
      - mmis1000 7y ago
        seccomp actually has that ability to allow only small portion of selective operations. Block everything except io is just one of its blocking mode. And the list is even configurable. Docker do use such ability to filter out sys-calls that shouldn't be used in the container.

segfaultbuserr 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, 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.

simion314 7y ago

Delaying the fixes is probably making them more money, if they lose a few more percent of performance they lose the number one position on all possible use cases/workflows , the PR hit will be huge, people could demand refunds or compensation (I mean you just sold them an expensive product without disclosing it is insecure and it will lose it's performance)

deleted 7y ago

[deleted]

josteink 7y ago

> This is troubling. Only for people who for whatever reason still continue to buy Intel-based systems.