More Intel speculative execution vulnerabilities • Hacker News Board

Re: More Intel speculative execution vulnerabilities

#121

Post by jjoonathan » Wed, Nov 13, 2019, 2:25 PM UTC

S_A_P wrote: post #86

segfaultbuserr wrote: post #71

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…

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…

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.

Re: More Intel speculative execution vulnerabilities

#122

Post by gmueckl » Wed, Nov 13, 2019, 2:28 PM UTC

zzzcpan wrote: post #109

wolf550e wrote: post #55

Earlier quoted context omitted.

There used to be a time when people thought relying on if statements for security was enough and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs. Now we know better. 1 - https://en.wikipedia.org/wiki/Singularity_(operating_system)

> and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs WebAssembly doubles down on it today. Technically, though, software isolated lightweight processes within the same address space is still a very real possibility, it's just that isolation is up to the compilers now that have to emit spectre-proof code, so no native blobs. Which, let's get real, has to happen sooner or la…

You can't trust any computation on hardware that cannot be trusted. There is no way to check that. Any software implemented check to detect that can be thwarted by hardware that misbehaves in malicious ways. Imagine an address based instruction replacement table that is used to convert some key consitional branches into unconditional ones.

Re: More Intel speculative execution vulnerabilities

#123

Post by the_duke » Wed, Nov 13, 2019, 2:29 PM UTC

kjs3 wrote: post #118

mywacaday wrote: post #56

Earlier quoted context omitted.

I'm nearly 20 years in mid to large companies, I've never seen an AMD cpu on a desktop, laptop or server. Its almost like nobody ever gets fired for buying Intel.

I'm 30+ years in. AMD shipped huge numbers of 8086/8088s as a second-source; you might have had one and not known it. But I'm guessing that's not what you mean. :-) There was a good bit of time where Opterons where everywhere on servers, including things like the whole Sun x86 line. At one gig we had datacenters full of IBM blade servers stuffed with dual Opteron boards; they were a big success in the market. I know…

I've heard that AMD suddenly pulling out of the server market was very damaging for the relationship with vendors, hence (in part) their trouble of getting back in the door .

But it does seem that adoption is growing again, with recent performance figures and the attractive price point.

Re: More Intel speculative execution vulnerabilities

#124

Post by gmueckl » Wed, Nov 13, 2019, 2:32 PM UTC

wolf550e wrote: post #94

zaphirplane wrote: post #91

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?

Nothing like that happens. Writes to dram or pcie devices or data bus cannot be rolled back. You have a misunderstanding of what speculative execution entails. The things that get rolled back are writes to general purpose registers.

How is this implemented? Undoing register renaming?

Re: More Intel speculative execution vulnerabilities

#125

Post by scandinavian » Wed, Nov 13, 2019, 2:33 PM UTC

dijit wrote: post #117

scandinavian wrote: post #80

Earlier quoted context omitted.

>The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. Oh, so it just takes more time, so you have knowledge of an exploit? Fine, show me any PoC or similar bypassing the lower accuracy and site isolation. You are such a big part of the problem with how this whole class of exploits have been handled. No technical knowledge, just spewing stuff like "You're th…

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. This is not misinformation, _you_ are spreading "certainty" of safety surrounding a dangerous idea. https://spectreattack.com/spectre.pdf Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolu…

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

>Even if I was wrong, and very wrong, why the hell would you choose to be less safe? this whole thread chain is absolutely baffling. Buy an AMD CPU or leave the mitigations on. Everything else is needlessly opening yourself up.

I don't run without migrations. I commented on the original parent comments threat model and that I think it's perfectly logical. And I maintain this, if your threat model is so strict, that you are afraid of speculative execution vulnerabilities hitting you through javascript, you should not run JS at all, as regular js 0days have hit while no actual speculative execution browser exploits have hit.

Re: More Intel speculative execution vulnerabilities

#126

Post by MiroF » Wed, Nov 13, 2019, 2:37 PM UTC

scandinavian wrote: post #28

wolf550e wrote: post #23

Earlier quoted context omitted.

Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.

There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes. It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't…

> There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0).

sure dude, sure

Re: More Intel speculative execution vulnerabilities

#127

Post by monocasa » Wed, Nov 13, 2019, 2:43 PM UTC

gmueckl wrote: post #124

wolf550e wrote: post #94

Earlier quoted context omitted.

Nothing like that happens. Writes to dram or pcie devices or data bus cannot be rolled back. You have a misunderstanding of what speculative execution entails. The things that get rolled back are writes to general purpose registers.

How is this implemented? Undoing register renaming?

Exactly. Also not committing writes that are almost in the store buffer.

Re: More Intel speculative execution vulnerabilities

#128

Post by nradov » Wed, Nov 13, 2019, 2:44 PM UTC

cookiecaper wrote: post #50

segfaultbuserr wrote: post #31

Earlier quoted context omitted.

Hewlett-Packard was an electronic engineering, semiconductor, and computing company from the beginning (the first product they sold was an audio distortion analyzer, it used a creative circuit to achieve high performance at minimum cost), they used to do serious and innovative R&D. There were the glorious days when Hewlett-Packard makes state-of-art test equipment and semiconductor devices, developed in-house enterpr…

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

#129

Post by scandinavian » Wed, Nov 13, 2019, 2:51 PM UTC

MiroF wrote: post #126

scandinavian wrote: post #28

Earlier quoted context omitted.

There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes. It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't…

> There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). sure dude, sure

Chrome: CVE-2019-13720, CVE-2019-5786 Firefox: CVE-2019-11707/CVE-2019-11708

Your turn. Link the speculative execution 0days.

Re: More Intel speculative execution vulnerabilities

#130

Post by smolder » Wed, Nov 13, 2019, 2:51 PM UTC

segfaultbuserr wrote: post #76

emerongi wrote: post #75

Earlier quoted context omitted.

Not saying this happened at IBM, but sometimes correct people can be promoted into correct positions, in which case the company keeps going just fine. However, at some point any company is probably bound to promote wrong people, who will end up promoting/hiring the wrong people under them, eventually completely changing the course of the business. It seems like the death of a company is inevitable.

> It feels like the death of a company is inevitable. Which, from a higher perspective, is good. As it breaks down monopolies and give way to more innovative new companies.

It's good when we allow them to fail gracefully. I would hate to see what unscrupulous stuff a failing Google could do with all our info being held hostage.