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

161–170 of 365 posts

Re: New speculative attacks on Apple CPUs

#161

Post by throneaway1799 »

lxgr wrote: post #88
tptacek wrote: post #86

Earlier quoted context omitted.

I think at the point where you're suggesting 1hz bytecode interpreters the onus is kind of on you to be clear you're not talking about plausible points in the design space.

1 Hz is probably a bit too slow for practical applications, but my point is that somewhere between that, and simulating a parallel universe at each data-dependent branch, is probably a reasonably-safe spot, or more likely a spectrum that application developers get to pick their tradeoffs from.

An identically useful comment would've been to place the bounds at 0 and infinity.

Re: New speculative attacks on Apple CPUs

#162

Post by dadrian »

lxgr wrote: post #34
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…

That's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1]. By setting a different policy, sites can protect themselves against this. I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a maj…

It is not required by window.open semantics, you can absolutely implement site isolation even in the presence of COOP unsafe-none

Re: New speculative attacks on Apple CPUs

#163

Post by lxgr »

plufz wrote: post #142
lxgr wrote: post #123

Earlier quoted context omitted.

Announce what to whom? To the hundreds of millions of users out there that don't even know what a browser is , let alone why it's now talking to them about something called a "site isolation framework"?

I would guess you would use a deprecation message in the console? Like they have done over cookie changes, etc. A normal user would obviously not check the console, but the devs or admins of the site sure might.

That's assuming there's still a dev around that has knowledge of, or even access to, the source code of a given webapp depending on the legacy functionality.

Re: New speculative attacks on Apple CPUs

#164

Post by fsflover »

autoexec wrote: post #122
basementcat wrote: post #37

Earlier quoted context omitted.

If your machine is air gapped and/or not running random downloaded code, I think it is a possible reasonable option.

It's a tragedy that so many websites insist on having the ability to run random downloaded code on our systems to do basic things like displaying simple text and images. Things browsers are capable of with nothing but HTML. Google refuses to even show search results, a bunch of literal hyperlinks, without javascript being enabled.

> Google refuses to even show search results, a bunch of literal hyperlinks, without javascript being enabled.

DuckDuckGo works fine with no JS.

Re: New speculative attacks on Apple CPUs

#165

Post by [deleted] »

kllrnohj wrote: post #35
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…

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.

[deleted]

Re: New speculative attacks on Apple CPUs

#166

Post by lxgr »

astrange wrote: post #140
eptcyka wrote: post #96

Earlier quoted context omitted.

Other browsers do site isolation, why can’t Safari? (:

Have you noticed how often people complain Chrome uses too much memory?

Process-per-site isolation doesn't necessarily have to use (much) more memory.

If you pre-initialize the renderer and JavaScript engine and then fork that pre-warmed instance for each site, every page of memory not written to remains shared in physical memory.

Properly accounting for that in task managers is hard, though; on many OSes, Chrome's memory usage looks much scarier than it is in reality.

Re: New speculative attacks on Apple CPUs

#167

Post by School-Cotton »

IshKebab wrote: post #133
School-Cotton wrote: post #93

Earlier quoted context omitted.

But M1 is squarely a modern CPU. It uses all the techniques you mention (as does every high-performance CPU since the Pentium Pro era).

Does it have a Load Value Predictor?

I don't know.

Re: New speculative attacks on Apple CPUs

#168

Post by nine_k »

astrange wrote: post #140
eptcyka wrote: post #96

Earlier quoted context omitted.

Other browsers do site isolation, why can’t Safari? (:

Have you noticed how often people complain Chrome uses too much memory?

Because long-inactive tabs should go to sleep.

If Chrome itself is not aggressive enough, try the "Auto Tab Discard" extension.

Re: New speculative attacks on Apple CPUs

#169

Post by School-Cotton »

daneel_w wrote: post #157
School-Cotton wrote: post #90

Earlier quoted context omitted.

In my experience SMT is still faster for most workloads even with the mitigations.

It's a common misunderstanding that the CPU suddenly has twice as large performance envelope when SMT is enabled. Only specialized software/scenarios will tangibly benefit from the parasitic gains of SMT-induced extra parallelization, e.g. video encoders like x264 or CPU-bound raytracers to name a few examples. These gains typically amount to about 15-20% at the very extreme end. In some cases you'll see a performanc…

> It's a common misunderstanding that the CPU suddenly has twice as large performance envelope when SMT is enabled.

Perhaps, but I am not under this misunderstanding and never expressed it.

> Only specialized software/scenarios will tangibly benefit from the parasitic gains of SMT-induced extra parallelization

In my experience it also speeds up C++/Rust compilation, which is the main thing I care about. I can't find any benchmarks now but I have definitely seen a benefit in the past.

Post reply on HN