Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

Post reply on HN
Print view View original

71–80 of 365 posts

Re: New speculative attacks on Apple CPUs

#71

Post by kevingadd »

bawolff wrote: post #65

Hmm, one part i found interesting > In order to make cache hits distinguishable from misses in Safari, we reference the NOT gate-based cache amplifica- tion primitive from [29, Section 5], adjusting the speculation parameters for the M2 CPU. We run the amplifier 500 times when the target address is cached and 500 more times when it is evicted, in native and WebAssembly implementations. Table 3 summarizes the timing d…

It delayed viable attacks by a few years, maybe?

It doesn't hurt that setbacks for web app development coincidentally send developers into the open arms of Google and Apple's stores that collect a 30% cut of all revenue, so there was a good incentive to do it even if it didn't protect anyone.

Re: New speculative attacks on Apple CPUs

#72

Post by hinkley »

sodality2 wrote: post #19
gjsman-1000 wrote: post #7

Bizarre the M1 is immune to both; I'm more secure by not upgrading. (Sure, there's still a few, but they are mostly minor by comparison, or newer chips are also affected.)

Newer CPUs use more and more "hacks" - out of order execution, caching, speculative execution, branch prediction, etc - to gain performance improvements. The further back you go, the less vulnerable CPUs generally are to these (but possibly more vulnerable to other kinds of attacks).

I can’t imagine taking a cpu design class in this more cynical era. So much of the speed these days seems to come down to distilling smoke and mirrors into physical form.

Re: New speculative attacks on Apple CPUs

#73

Post by jorvi »

umvi wrote: post #23
anotherhue wrote: post #3

For any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading. https://spectreattack.com/

Is it bad that I disable spectre mitigations on all my PCs to get a free double-digit-% performance boost?

You shouldn't disable Spectre mitigations, but Retbleed and Downfall (Intel) are much more of a "lab" exploit, and the fall-out for Retbleed is much more severe on cloud boxes than your personal PC. Easy 20-40% performance uplift on AMD Zen1-Zen2 and Intel 6th-11th gen.

Re: New speculative attacks on Apple CPUs

#74

Post by bawolff »

kevingadd wrote: post #71
bawolff wrote: post #65

Hmm, one part i found interesting > In order to make cache hits distinguishable from misses in Safari, we reference the NOT gate-based cache amplifica- tion primitive from [29, Section 5], adjusting the speculation parameters for the M2 CPU. We run the amplifier 500 times when the target address is cached and 500 more times when it is evicted, in native and WebAssembly implementations. Table 3 summarizes the timing d…

It delayed viable attacks by a few years, maybe? It doesn't hurt that setbacks for web app development coincidentally send developers into the open arms of Google and Apple's stores that collect a 30% cut of all revenue, so there was a good incentive to do it even if it didn't protect anyone.

> It doesn't hurt that setbacks for web app development coincidentally send developers into the open arms of Google and Apple's stores that collect a 30% cut of all revenue, so there was a good incentive to do it even if it didn't protect anyone.

That seems like a bit of a reach. Its an obscure feature that is rarely useful, and when it is all you have to do is send the right http header (if using chrome) and you get it back.

Re: New speculative attacks on Apple CPUs

#75

Post by yencabulator »

ajross wrote: post #54
omcnoe wrote: post #42

Earlier quoted context omitted.

It's not remote code execution, it's the same flavor of "out of bounds read through speculation" as previous vulnerabilities. It's terrifying because they have a working proof of concept from untrusted JS in Safari, but there have been speculative execution in browser JS engines before now also.

The language seems to argue otherwise: SLAP "allows the adversary to jump the LAP to the target webpage's string and trick the CPU into operating on it" and FLOP "allows us to run a function with the wrong arguments". That's absolutely not mere data exfiltration. Now, maybe this is because of a trampoline based on pre-existing Safari bugs and not the CPU misfeature itself. Again, the details are slim. But "the same f…

My read: the attack gets 600 cycles of CPU time to execute its code (JITted Javascript, in web context) on the speculated data, and to use some side channel to communicate results back out of the speculated parallel-world.

Some of the earlier speculation attacks didn't get to do arbitrary compute on the speculated data, they could only for example influence whether something was loaded into cache or not.

This makes an attack easier to write.

Re: New speculative attacks on Apple CPUs

#76

Post by sodality2 »

hinkley wrote: post #72
sodality2 wrote: post #19

Earlier quoted context omitted.

Newer CPUs use more and more "hacks" - out of order execution, caching, speculative execution, branch prediction, etc - to gain performance improvements. The further back you go, the less vulnerable CPUs generally are to these (but possibly more vulnerable to other kinds of attacks).

I can’t imagine taking a cpu design class in this more cynical era. So much of the speed these days seems to come down to distilling smoke and mirrors into physical form.

On the other hand, research into finding these vulnerabilities seems to be booming. Though presumably, so is the grey-hat market.

Re: New speculative attacks on Apple CPUs

#77

Post by amelius »

omcnoe wrote: post #30
junek wrote: post #11

OK, fun. What can we do to mitigate this until it gets patched?

Serious answer, don't use Safari. Use a browser that properly separates webpages into isolated processes so that this kind of cross-site read is not possible.

Will that work? Isn't memory treated in a unified way between processes, at some point?

Re: New speculative attacks on Apple CPUs

#78

Post by kllrnohj »

lxgr wrote: post #44
kllrnohj wrote: post #35

Earlier quoted context omitted.

The writing was on the wall for in-process sandboxing with Spectre, but that seems to have faded a bit. This just re-enforces that. Things like "safe in-process sandboxing with WASM" are just a fantasy, it can't be implemented.

Safe in-process sandboxing is obviously possible and even trivial. It does get harder if you care about performance, though.

"trivial" how do you figure? Remember these exploits bypass your own code's conditionals over a shockingly far duration. Unless you just mean for incredibly restrictive usages such as eBPF?

possible absent any performance concerns at all, yeah sure

Re: New speculative attacks on Apple CPUs

#79

Post by kevingadd »

bawolff wrote: post #74
kevingadd wrote: post #71

Earlier quoted context omitted.

It delayed viable attacks by a few years, maybe? It doesn't hurt that setbacks for web app development coincidentally send developers into the open arms of Google and Apple's stores that collect a 30% cut of all revenue, so there was a good incentive to do it even if it didn't protect anyone.

> It doesn't hurt that setbacks for web app development coincidentally send developers into the open arms of Google and Apple's stores that collect a 30% cut of all revenue, so there was a good incentive to do it even if it didn't protect anyone. That seems like a bit of a reach. Its an obscure feature that is rarely useful, and when it is all you have to do is send the right http header (if using chrome) and you get…

Multithreading may be an obscure feature to you but runtime developers get requests for it all the time. SAB becoming widely available was definitely delayed.

Re: New speculative attacks on Apple CPUs

#80

Post by LPisGood »

anotherhue wrote: post #3

For any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading. https://spectreattack.com/

I’d highly recommend reading Flush+Reload first since the cache side channel is key to any of these miceoarchitectural attacks.
Post reply on HN