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

351–360 of 365 posts

Re: New speculative attacks on Apple CPUs

#351

Post by adgjlsfhk1 »

adrian_b wrote: post #327
eigenform wrote: post #321

Earlier quoted context omitted.

> for x86-64 CPUs it is very unlikely that a load value predictor can be worthwhile I think you're making a good point about immediate encodings probably making ARM code more amenable to LVP, but I'm not sure I totally buy this statement. If you take some random x86 program, chances are there are still many loads that are very very predictable. There's a very recent ISCA'24 paper[^1] about this (which also happens to…

Unfortunately what you say is true for many legacy programs, but it is a consequence of the programs not being well structured by the programmer, or not being well optimized by the compiler, or due to a defect of the ISA, other than the lack of big immediate constants. Some of the global-stable values are reloaded because the ISA does not provide enough explicitly-addressable registers, despite the fact that a modern…

I think you're under-estimating the amount of pointer chasing that lots of types of code has to do. B-Tree traversal for filesystems, mark loops for garbage collection, and sparse graph traversal are all places where you're doing a lot of pointer chasing.

Re: New speculative attacks on Apple CPUs

#352

Post by saagarjha »

coldpie wrote: post #336
thijsr wrote: post #33

Earlier quoted context omitted.

It depends on your threat model. If you don't run any untrusted code on your hardware (including Javascript), you can safely disable the mitigations. If you do run untrusted code, keep them enabled.

In the context of a regular end-user desktop machine, this seems overly paranoid to me. The odds of encountering a real, JS-based spectre attack in the wild are basically zero (has anyone ever seen a browser-based Spectre attack outside of a research context? even once?), and the odds of it then being able to retrieve actual sensitive data are also basically zero. That's two astonishingly tiny numbers multiplied toge…

Spectre is mitigated by your browser already.

Re: New speculative attacks on Apple CPUs

#354

Post by saagarjha »

jmkni wrote: post #301
goldsteinq wrote: post #99

Earlier quoted context omitted.

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.

So could this hypothetically open a mail client on your iPhone and read your emails?

No, it doesn’t do cross-address space attacks.

Re: New speculative attacks on Apple CPUs

#355

Post by ngneer »

leeter wrote: post #271
MikeHolman wrote: post #260

Earlier quoted context omitted.

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 exam…

Your friend is genuine in their interpretation, but there is definitely more to the discussion than the zero sum game they allude to. One can have both performance and security, but sometimes it boils down to clever and nuanced design, and careful analysis as you point out.

Re: New speculative attacks on Apple CPUs

#356

Post by anyfoo »

hmry wrote: post #338
saagarjha wrote: post #174

Earlier quoted context omitted.

Grouping a hex address by threes is crazy

3 hex digits = 12 bits = 4096 entries, the size of each address translation table on ARM. So it does make some (twisted) sort of sense. Assuming you're using 4k page size

Apple devices use 16kB pages.

Re: New speculative attacks on Apple CPUs

#360

Post by astrange »

fc417fc802 wrote: post #350
astrange wrote: post #345

Earlier quoted context omitted.

> You’re taking large blocks of data, and performing uniform mathematical operations over all the data to perform what is effectively statistical analysis of that data. It doesn't behave this way. If you're thinking of the DCT it uses that's mostly 4x4 which is not very large. As for motion analysis there are so many possible candidates (since it's on quarter-pixels) that it can't try all of them and very quickly sta…

> it uses that's mostly 4x4 which is not very large That's 16x32 which is AVX512. What other size would you suggest using and (more importantly) what commercially available CPU architecture are you running it on?

4x4 is 4x4, not 16x32?
Post reply on HN