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

341–350 of 365 posts

Re: New speculative attacks on Apple CPUs

#341

Post by daneel_w »

avianlyric wrote: post #211
daneel_w wrote: post #157

Earlier quoted context omitted.

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…

Are you sure about your statement > 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. Normally those types of compute heavy processes, data streamlined, processes don’t see much benefit from SMT. After all SMT only provides a performance benefit by allowing the CPU to pull from two distinct chains of instructions, and fill th…

> Are you sure about your statement

Yes. From actual experience.

Re: New speculative attacks on Apple CPUs

#342

Post by phatskat »

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…

The first two, screen wake lock and web serial have good use cases imo. I wouldn’t be surprised if some in-use assistive technology uses serial communication - think screen readers or custom input devices. Keeping the screen from locking is also useful from a purely accessible standpoint as well for users who move slower or need more time to read things.

Re: New speculative attacks on Apple CPUs

#343

Post by saagarjha »

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

macOS/iOS don’t

Re: New speculative attacks on Apple CPUs

#345

Post by astrange »

avianlyric wrote: post #311
astrange wrote: post #236

Earlier quoted context omitted.

Compression is inherently unpredictable (if you can predict it, it's not compressed enough), which is vaguely speaking how it can help x264.

I agree that compression is all about increasing entropy per bit, which makes the output of a good compressor highly unpredictable. But that doesn’t mean the process of compression involves significant amounts of unpredictable branching operations. If for no other reason than it would be extremely slow and inefficient, because many branching operations means you’re either processing input pixel-by-pixel, or your SIMD…

> 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 starts trying to filter them out.

Re: New speculative attacks on Apple CPUs

#346

Post by indymike »

lxgr wrote: post #171
zamalek wrote: post #111

Earlier quoted context omitted.

We had the tech in the 80's for the browser to facilitate popup authentication with process isolation. It's this niche and esoteric tech called IPC[1], so niche that one really can't blame Apple for not hearing about it. It truly boggles the mind as to how all the other browsers pull it off. [1]: https://en.wikipedia.org/wiki/Inter-process_communication

To be fair, there wasn't that much sensitive web content around in the 80s to leak (primarily due to the web not yet existing, nor browsers), so it's only fair that browsers didn't consider using IPC for site isolation back then.

To be fair, there was no web in the 80s.

Re: New speculative attacks on Apple CPUs

#347

Post by indymike »

fennecbutt wrote: post #234
lxgr wrote: post #188

Earlier quoted context omitted.

Well, for better or worse, the web is an application platform these days. I consider it pretty great, since the alternative is installing native apps for things I'm using exactly once or very rarely. There's a case to be made though that maybe these things should only be available to PWAs, which is what Apple is already doing for some functionality on iOS, including push notifications.

What? I thought Apple was trying to quietly kill pwas, probably bc they don't go thru their app store. And also bc if you make a good enough sandbox then you don't need to pay for "all the wooork we put in"

iOS just really improved support for pwas sometime in the last part of last years. It's much better.

Re: New speculative attacks on Apple CPUs

#348

Post by fulafel »

alphabetting wrote: post #189

Is the statement from Apple just PR or is this not a usable exploit? "Based on our analysis, we do not believe this issue poses an immediate risk to our users." https://www.bleepingcomputer.com/news/security/new-apple-cpu...

And from the paper seems like they played it interestingly in the researchers direction as well:

"1.2. Responsible Disclosure

We disclosed our results to Apple on May 24, 2024. Apple’s Product Security Team have acknowledged our report and proof-of-concept code, requesting an extended embargo beyond the 90-day window. At the time of writing, Apple did not share any schedule regarding mitigation plans concerning the results presented in this paper. "

Re: New speculative attacks on Apple CPUs

#349

Post by fc417fc802 »

positr0n wrote: post #264
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.

What is the threat model if I run lots of untrusted JavaScript, but I only have a small amount of memory in other processes worth reading and I would notice sustained high CPU usage? Is there an example in the wild of a spectre exploit stealing my gmail cookie and doing something with it? (Would be difficult since it's tied to other fingerprints like my IP) Or stealing credit card numbers when they're in memory after…

[dead]

Re: New speculative attacks on Apple CPUs

#350

Post by fc417fc802 »

astrange wrote: post #345
avianlyric wrote: post #311

Earlier quoted context omitted.

I agree that compression is all about increasing entropy per bit, which makes the output of a good compressor highly unpredictable. But that doesn’t mean the process of compression involves significant amounts of unpredictable branching operations. If for no other reason than it would be extremely slow and inefficient, because many branching operations means you’re either processing input pixel-by-pixel, or your SIMD…

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

Post reply on HN