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

81–90 of 365 posts

Re: New speculative attacks on Apple CPUs

#81

Post by lxgr »

kllrnohj wrote: post #78
lxgr wrote: post #44

Earlier quoted context omitted.

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

> Unless you just mean for incredibly restrictive usages such as eBPF?

I was actually thinking something more like a bytecode interpreter that runs one operation and then sleeps until the next full wall clock second, but yes, that's my point: If you don't care about performance, you can make process isolation safe very easily.

Re: New speculative attacks on Apple CPUs

#82

Post by yoshicoder »

Funny that I am seeing this now, because last Fall I had Daniel Genkin as my Intro to Cyber Security Professor (co-author of this result). Interesting class, but I remember him mentioning that they were working on a speculative attack for Apple CPUs after seeing the results of spectre and meltdown on Intel CPUs. I remember how he seemed almost paranoid about security, and I suppose I see why now (security is almost never guaranteed).

Especially now that I have just bought an M4 mac

Re: New speculative attacks on Apple CPUs

#83

Post by bawolff »

kevingadd wrote: post #79
bawolff wrote: post #74

Earlier quoted context omitted.

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

I would still maintain that needing multithreading on a website is relatively rare, and specifically needing SharedArrayBuffer instead of just multiple proceses (e.g. webworkers) is even more rare.

Did use cases exist? Sure. But not sufficiently to move the needle on app store usage.

Re: New speculative attacks on Apple CPUs

#84

Post by tptacek »

gabeio wrote: post #68
tptacek wrote: post #32

Earlier quoted context omitted.

The LVP vulnerability was reported in September, for what it's worth.

That's still more or less 120 days ago. Well over the 90 day typical window.

I'm not saying it's bad (I'm pretty close to a disclosure absolutist), though I don't really know what the norms are for hardware attacks --- both papers are well past the normal coordinated disclosure window for software.

Re: New speculative attacks on Apple CPUs

#86

Post by tptacek »

lxgr wrote: post #81
kllrnohj wrote: post #78

Earlier quoted context omitted.

"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

> Unless you just mean for incredibly restrictive usages such as eBPF? I was actually thinking something more like a bytecode interpreter that runs one operation and then sleeps until the next full wall clock second, but yes, that's my point: If you don't care about performance, you can make process isolation safe very easily.

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.

Re: New speculative attacks on Apple CPUs

#87

Post by tptacek »

r00fus wrote: post #31
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…

Do other browsers have process isolation for new tabs?

Not necessarily for tabs on the same web site, but for different sites, yes. Hence "site isolation".

Re: New speculative attacks on Apple CPUs

#88

Post by lxgr »

tptacek wrote: post #86
lxgr wrote: post #81

Earlier quoted context omitted.

> Unless you just mean for incredibly restrictive usages such as eBPF? I was actually thinking something more like a bytecode interpreter that runs one operation and then sleeps until the next full wall clock second, but yes, that's my point: If you don't care about performance, you can make process isolation safe very easily.

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.

Re: New speculative attacks on Apple CPUs

#89

Post by tptacek »

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.

I agree that 1hz is probably too slow for practical applications.

Re: New speculative attacks on Apple CPUs

#90

Post by School-Cotton »

daneel_w wrote: post #48
umvi wrote: post #23

Earlier quoted context omitted.

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

You're not getting a boost, you're avoiding a penalty. In some (but not all) cases you can avoid the penalty and the exploits by disabling SMT. Remember, SMT isn't twice as many cores, just twice as many half-cores. You'll be fine.

In my experience SMT is still faster for most workloads even with the mitigations.
Post reply on HN