Live data from Hacker News

More Intel speculative execution vulnerabilities

mdsattacks.com

161–170 of 262 posts

Re: More Intel speculative execution vulnerabilities

#161
post #4

Another nail in the casket lake. Is the solution just to throw everything out and start again? Do we just abandon speculative execution?

Abandoning speculation entirely is too much. If you just go to in order with a reasonable pipeline length nobody has yet figured a way to smuggle out speculative state on something like an ARM A53. That means giving up performance but only a factor of 4 or so. Giving up speculation entirely would mean an order of magnitude larger performance loss.

Re: More Intel speculative execution vulnerabilities

#162
post #52

> 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…

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.

Re: More Intel speculative execution vulnerabilities

#163

Earlier 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.

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-...) and require a very specific set of skills to work with.

Re: More Intel speculative execution vulnerabilities

#164
post #150

Earlier 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 have misunderstood how the browser attacks work. They are limited to the memory assigned to the browser process. If site-isolation and the other browser mitigations were somehow bypassed, an ad-network would potentially be able to read some data from other loaded tabs.

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

#165

Ok 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?

Accesses to memory that is configured for device I/O (UnCacheable in x86 terms) are never speculated, so there’s nothing to roll back.

Re: More Intel speculative execution vulnerabilities

#166
post #137
post #9

Earlier 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…

L1TF was an incredibly stupid bug in Intel's L1 cache implementation. I very much doubt IBM's POWER chips had the same issue. Do you have any source for this?

Re: More Intel speculative execution vulnerabilities

#167

Earlier 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.

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

I'm not an EE, just my 0.02 USD.

Re: More Intel speculative execution vulnerabilities

#168
post #128

Earlier 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.

True, but if you can identify both the winner and the loser, say AMD and/or TSMC vs INTC, you could sell puts/spreads on the loser and sell calls/spreads on the winner in similar at-risk dollar amounts. If the market itself booms or busts through your strikes, gains on one side will cancel the losses on the other. While you're right, you make double money by winning on both sides. But you lose double if you're betting the wrong way.
Post reply on HN