Another nail in the casket lake. Is the solution just to throw everything out and start again? Do we just abandon speculative execution?
More Intel speculative execution vulnerabilities
161–170 of 262 posts
Re: More Intel speculative execution vulnerabilities
#162> 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, l…
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 cr…
Not an EE so I’m just dumping my thoughts.
Re: More Intel speculative execution vulnerabilities
#163Earlier quoted context omitted.
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 cr…
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.
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-...) and require a very specific set of skills to work with.
Re: More Intel speculative execution vulnerabilities
#164Earlier quoted context omitted.
>Except that the Spectre paper already takes degraded timers into account and suggests to use a Web Worker thread that increments a value in a loop as a replacement. Yeah, which was why SharedArrayBuffer was disabled when spectrev1 was released. It is still disabled in Chrome if site-isolation is disabled and it's still disabled in firefox. You should really know all this if you are so very well versed in the subject…
“Threat model is so strict” is weird to say when any ad network can access any and all memory on your desktop potentially. That’s a very wide attack scope.
You can't use the speculative execution vulnerabilities to just read all system memory using a javascript exploit. Like the exploit that is the topic of this post can't be used in a browser at all, as you are limited to what the JIT executes, you can't just execute TSX instructions in a browser.
You might be thinking of when you have native code execution.
Re: More Intel speculative execution vulnerabilities
#165Ok this has been bugging me for a while. How does speculative execution roll back side effect like write to disk or send a packet on the network, when the speculation is wrong. At a guess there are safe instructions that can be run when doing branch prediction?
Re: More Intel speculative execution vulnerabilities
#166Earlier quoted context omitted.
AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.
AMD processors were also vulnerable to spectre v2. I don't know the status of the mitigations or whether it was fixed in zen 2. EDIT: I found the list I made a few months back. no guarantees, but i think it is mostly accurate. Meltdown: Intel, IBM, some ARM Spectre v1: Intel, ARM, IBM, AMD Spectre v2: Intel, ARM, IBM, AMD Spectre v3a: Intel, ARM Spectre v4: Intel, ARM, IBM, AMD L1TF: Intel, IBM Meltdown-PK: Intel Spe…
Re: More Intel speculative execution vulnerabilities
#167Earlier quoted context omitted.
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 cr…
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.
> 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
I'm not an EE, just my 0.02 USD.
Re: More Intel speculative execution vulnerabilities
#168Earlier quoted context omitted.
HP was the Google of its day when H & P were in charge. People either retire or die eventually. What happens to Google when time claims Larry and/or Sergei? Not trying to besmirch or minimize early HP by comparing to Google -- probably better to use Musk/SpaceX or something -- but IMO this is the key takeaway that doesn't seem widely discussed. Innovative companies have innovative leaders with expert-level knowledge…
This is one reason why the current high stock market valuations for large, profitable tech companies are crazy. Eventually the corporate culture rots from the inside and they're overtaken by a disruptive competitor. Unfortunately there's no practical way for retail investors to take a short position on those stocks for 30 years in the future; regular options only go out about 3 years.
Re: More Intel speculative execution vulnerabilities
#169Is there a list of the exploits found 'in the wild' that depend on speculative execution?