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

271–280 of 365 posts

Re: New speculative attacks on Apple CPUs

#271

Post by leeter »

MikeHolman wrote: post #260
lxgr wrote: post #215

Earlier quoted context omitted.

Can't edit my original post anymore: Firefox and Chrome do seem to isolate even same-browsing-context-group and bridge the required APIs via IPC, so hopefully Safari will catch up at some point. Basically, there are three scenarios: - Completely unrelated tabs (e.g. those you open manually, those opened via command-click, tabs opened via ' " or 'rel="noopener"' references etc.) – these are relatively easily isolated…

I worked on a browser team when Spectre/Meltdown came out, and I can tell you that a big reason why Firefox and Chrome do such severe process isolation is exactly because these speculative attacks are almost impossible to entirely prevent. There were a number of other mitigations including hardening code emitted from C++ compilers and JS JITs, as well as attempts to limit high precision timers, but the browser vendor…

To add to this and to quote a friend who has more NDAs in regards to microarchitecture than I can count and thus shall remain nameless: "You can have a fast CPU or a secure CPU: Pick one". Pretty much everything a modern CPU does has side effects that are something that any sufficiently motivated attacker can find a way to use (most likely). While many are core specific (register rename, execution port usage for example), many are not (speculative execution, speculative loads). Side channels are a persnickety thing, and nearly impossible to fully account for.

Can you make a "Secure" CPU? In theory yes, but it won't be fast or as power efficient as it could in theory be. Because the things that allow those things are all possible side channels. This is why in theory the TPM in your machine is for those sorts of things (allegedly, they have their own side channels).

The harder question is "what is enough?" e.g. at what level does it not matter that much anymore? The answer based on the post above this is based on quite a lot of risk analysis and design considerations. These design decisions were the best balance of security and speed given the available information at the time.

Sure, can you build that theoretically perfect secure CPU? Yes. But, if you can't do anything that actually needs security on it because it's so slow; do you care?

Re: New speculative attacks on Apple CPUs

#272

Post by pjmlp »

amatecha wrote: post #186
kergonath wrote: post #158

Earlier quoted context omitted.

> Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites. And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.

idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browse…

I fully agree, as someone also doing Web development in a similar timeframe, for plenty of stuff we would be better with native apps talking over Internet protocols, no need to transform a platform for interactive documents into a OS.

Re: New speculative attacks on Apple CPUs

#273

Post by yard2010 »

omcnoe wrote: post #18

Their SLAP demo provides a great example of how defence-in-depth can make/break the viability of an exploit. That terrifying Safari demo is possible because Safari fails to isolate new windows in individual processes when calling `window.open` in js. All the other side channel magic presented here doesn't matter if the data you want to read is in a seperate process with sufficient separation from the "hostile" proces…

Safari is Internet Explorer of the 20'

Re: New speculative attacks on Apple CPUs

#274

Post by happosai »

MindSpunk wrote: post #258
happosai wrote: post #257

Earlier quoted context omitted.

There is extremely popular Cortex-A53 which is in-order core.

Yes and it's very slow as a result. In-order cores without speculative execution can't be fast. Not unless you have no memory and only operate out of something equivalent to L1 cache. Memory is slow. Insanely slow (compared to the CPU). You can process stupid fast if your entire working set can fit in a 2KB L1 cache, but the second you touch memory you're hosed. You can't hide memory latency without out-of-order exec…

Cortex a53 may be slow, but it's fast enough for very many tasks. Once you design the your data structures to fit L1/L2 caches it actually is pretty damn fast. Best part of cache aware data structure design it also makes code run faster on Out Of Order CPUS. A53 is of course slow if you use modern layer-upon-layer-ware as your architecture.

But I was just really trying to point that in-order cpus are still around, they did not disappear with in-order atom.

Re: New speculative attacks on Apple CPUs

#276

Post by saagarjha »

astrange wrote: post #235
avianlyric wrote: post #206

Earlier quoted context omitted.

That might be their point. As the OP quoted > any virtual address below 0x100, 000, 000 is invalid. That kinda suggests that all 32bit addresses are inherently invalid on 64bit MacOS

Not inherently, it's just a linker default. You can run 32-bit processes through WINE.

Only in Rosetta. On arm64 these binaries will not be allowed to load.

Re: New speculative attacks on Apple CPUs

#278

Post by dailykoder »

andrewia wrote: post #247
phendrenad2 wrote: post #239

Seems like speculative execution is just fundamentally insecure. With SPECTRE/MELTDOWN mitigations, doesn't CPU performance drop below the same CPU performance with no branch prediction at all? Should we move back to CISC? Or maybe VLIW?

I don't think so; speculative execution is the cornerstone of modern CPU performance. Even 15-year-old 32-bit ARM CPUs do it. The only phone/PC-grade processors without it are the first generation of Intel Atom, and I recall that early Atom processors sacrificed a ton of performance to keep power consumption low. I doubt this will change since mitigations are "good enough" to patch over major issues.

Maybe the boomers were right and we made computers way too complex? This might be a bit of a hyperbole, but seems like there will always be a security hole (even if mostly hard to exploit). But I also guess we can't get much faster without it either. So maybe we should reduce complexity. Atleast for safety critical systems.

Re: New speculative attacks on Apple CPUs

#279

Post by withinboredom »

amatecha wrote: post #254
not_kurt_godel wrote: post #242

Earlier quoted context omitted.

> The Screen Wake Lock API provides a way to prevent devices from dimming or locking the screen when an application needs to keep running. https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake ... There's an obscure use case for this called "Watching Video"

Dunno, that API has only been available since Firefox 126 and I've been watching videos without having my screen go to sleep (or screensaver coming on) for like.. years and years (far before Firefox 126)

That's because there used to be this thing called flash/silverlight that could do this instead. Now, video is done completely differently than it was.

Re: New speculative attacks on Apple CPUs

#280

Post by MagicMoonlight »

dailykoder wrote: post #278
andrewia wrote: post #247

Earlier quoted context omitted.

I don't think so; speculative execution is the cornerstone of modern CPU performance. Even 15-year-old 32-bit ARM CPUs do it. The only phone/PC-grade processors without it are the first generation of Intel Atom, and I recall that early Atom processors sacrificed a ton of performance to keep power consumption low. I doubt this will change since mitigations are "good enough" to patch over major issues.

Maybe the boomers were right and we made computers way too complex? This might be a bit of a hyperbole, but seems like there will always be a security hole (even if mostly hard to exploit). But I also guess we can't get much faster without it either. So maybe we should reduce complexity. Atleast for safety critical systems.

Now wait until the zoomers come along and take the lead on these products. They grew up with iPads and no file system. It’s going to be chaos!
Post reply on HN