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

141–150 of 365 posts

Re: New speculative attacks on Apple CPUs

#141

Post by asoneth »

lxgr wrote: post #69
omcnoe wrote: post #63

Earlier quoted context omitted.

Cross-Origin-Opener-Policy seems like a case of bad defaults where a less secure option has been selected so that we don't break some poorly maintained websites. Better to get the actual users of `window.open` to fix their code than to make every website insecure out of the box. I can't imagine there are many sites passing significant amounts of data through this, the small number of users where IPC poses too high a…

Forcing every website to adapt to a browser update is completely infeasible. > I can't imagine there are many sites passing significant amounts of data through this This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).

Why not a choice?

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.

Re: New speculative attacks on Apple CPUs

#142

Post by plufz »

lxgr wrote: post #123
dfedbeef wrote: post #100

Earlier quoted context omitted.

You just announce you are making a change and then turn it on later.

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.

Re: New speculative attacks on Apple CPUs

#143

Post by ijustlovemath »

tptacek wrote: post #25

Cool detail, in the section where they reverse-engineer the presence of an LVP on the M3: Remarkably, while all other load widths activate the LVP on any constant value fitting that width, we observe that acti- vation on 8-byte wide loads occurs only when the load value is zero. We conjecture that this may be a countermeasure for memory safety such that the LVP will not learn values of pointers. That is, with the M3…

wait, so does this mean that if an exploit tries to use a 32 bit address it's immediately shut down?

Re: New speculative attacks on Apple CPUs

#145

Post by anyfoo »

ijustlovemath wrote: post #143
tptacek wrote: post #25

Cool detail, in the section where they reverse-engineer the presence of an LVP on the M3: Remarkably, while all other load widths activate the LVP on any constant value fitting that width, we observe that acti- vation on 8-byte wide loads occurs only when the load value is zero. We conjecture that this may be a countermeasure for memory safety such that the LVP will not learn values of pointers. That is, with the M3…

wait, so does this mean that if an exploit tries to use a 32 bit address it's immediately shut down?

There are usually no valid 32 bit addresses, i.e. the first 4GB are not mapped.

Re: New speculative attacks on Apple CPUs

#146

Post by api »

I bet you could construct a hard proof that any kind of speculation is insecure in the sense that it cannot be proven secure.

If that's not true, then someone's going to figure out exactly how to set bounds on safe speculation and that will become part of future CPU designs.

Re: New speculative attacks on Apple CPUs

#147

Post by eigenform »

twoodfin wrote: post #119

This introduced me to the idea of load value predictors. Is Apple the only chip designer using these in commercially released microarchitecture?

Probably not, but I don't think anyone has talked about it explicitly.

Otherwise, there are known examples of related-but-less-aggressive optimizations for resolving loads early. I'm pretty sure both AMD[^1] and Intel[^2] have had predictive store-to-load forwarding.

edit: Just noticed the FLOP paper also has a nice footnote about distinguishing LVP from forwarding during testing (ie. you want to drain your store queue)!

[^1]: https://www.amd.com/content/dam/amd/en/documents/processor-t...

[^2]: https://www.intel.com/content/www/us/en/developer/articles/t...

Re: New speculative attacks on Apple CPUs

#150

Post by prmoustache »

goldsteinq wrote: post #99
omcnoe wrote: post #30

Earlier quoted context omitted.

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.

There’re no other browsers on iPhone. Every iPhone browser is a reskin of Safari. They’re in theory supposed to allow other browsers in the EU, but AFAIK it has not happened yet.

Then don't use an iPhone until it is patched.
Post reply on HN