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

311–320 of 365 posts

Re: New speculative attacks on Apple CPUs

#311

Post by avianlyric »

astrange wrote: post #236
avianlyric wrote: post #211

Earlier quoted context omitted.

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…

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 pipeline is full of dead zones that you can’t actually re-schedule, because it would desync your processing waves.

Video compression is mostly very clever signal processing built on top of primitives like convolutions. 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. That analysis can then be used to drive a predictor, then you “just” need to XOR the predictor output with the actual data, and record the result (using some kind of variable length encoding scheme that lets you remove most of the unneeded bytes).

But just like computing the median of a large dataset can be done with no branches, regardless of how random or the large the input is. Video compression can also largely be done the same way, and indeed has to be done that way to be performant. There’s no other way to cram up to 4k * 3bytes per frame (~11MB) through a commercial CPU to perform compression at a reasonable speed. You must build your compressor on top of SIMD primitives, which inherently makes branching extremely expensive (many orders of magnitude more expensive than branching SISD operations).

Re: New speculative attacks on Apple CPUs

#312

Post by jazzyjackson »

padenot wrote: post #295
amatecha wrote: post #254

Earlier quoted context omitted.

Dunno, that API has only been available since Firefox 126 and I've been watching videos without having my screen go to sleep (or screensaver coming on) for like.. years and years (far before Firefox 126)

Indeed. I work on the Firefox media stack and we have been grabbing wake locks when video playback is happening for a long time. Occasionally e.g. on some linux desktop variant this has malfunctioned and we're alerted in no time and fix it. The Wake Lock API is for other use cases, such as recipe websites, or other document for which you don't want the screen to go away / dim, the kind where you happen to need to loo…

Bless you. I was driven a little mad once trying to figure out why certain websites would steal audio focus away from music playing on my phone, it must have been some clumsy implementation of this.

Re: New speculative attacks on Apple CPUs

#313

Post by twoodfin »

adrian_b wrote: post #306
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?

In many CPU ISAs, load value predictors are unlikely to be useful, because they cannot guess the value that will be loaded with an acceptable probability. The ARM ISA and also other ISAs with fixed-length instruction encoding are an exception. Because they have a fixed instruction length, typically of 32 bits, most constants cannot be embedded in the instruction encoding. As a workaround, when programming for such IS…

Thank you, fantastic answer.

I do wonder if there are other common code patterns that a practical LVP could exploit. One that comes to mind immediately are effectively constants at one remove: Think processing a large array of structs with long runs of identical values for some little-used parameter field. Or large bitmasks that are nearly all 0xFF or 0x00.

Re: New speculative attacks on Apple CPUs

#314

Post by avianlyric »

iforgot22 wrote: post #214
ActorNightly wrote: post #181

Earlier quoted context omitted.

>hackers are probably still motivated enough to try it. The amount of actual exploit crafting that is needed to actually do something meaningful with a hack is pretty much not worth doing for any financial reason. The only time this happens now is when state funded actors or prominent groups with lots of manpower really want to take down an individual person.

Depends how automated it can be. I know some non-spectre 0-days were used broadly, either via viruses or port-scanning. Is it possible to craft some JS that'll use a spectre-like vuln to reliably grab something important like Chrome passwords or credit cards? Idk, it's hard to prove otherwise, and hackers have more time to think about this than I do.

> Is it possible to craft some JS that'll use a spectre-like vuln to reliably grab something important like Chrome passwords or credit cards?

Probably, but there’s a huge luck element involved, at least with spectre. It’s difficult to guide the speculative execution to read exactly what you want it to read, assuming you even know where it is. As a result you need to spend quite a bit of time on a single target before you’re likely to actually get the data you want. Even then, there’s likely a significant element of human analysis to assemble something useful from all the noise.

So yes, it’s almost certainly possible. But exploits don’t exist in a vacuum. If you’re expending that much effort to get credit card numbers, then quite frankly you’re a fool, because good old phishing attacks and other social engineering attacks are easier, more reliable, and above all, cheaper.

At the end of the day, crime is a business like any other, profitability and margins are king. You don’t waste time perfecting attacks that have significantly smaller margins than your existing attacks. The only exception to that is nation states, because they aren’t motivated by directly extracting cash from victims, and ultimately that’s what makes nation state actors so dangerous.

Re: New speculative attacks on Apple CPUs

#315

Post by kllrnohj »

AHTERIX5000 wrote: post #285
kllrnohj wrote: post #39

Earlier quoted context omitted.

What are you doing where you see anything remotely close to double-digit-% gains from disabling spectre mitigations?

If mitigations include disabling SMT and the workload is compiling code, then the difference is easily in double digits.

What OS ships the mitigation of disabling SMT by default? Surely they just meant things like the retpoline mitigations in syscalls?

Re: New speculative attacks on Apple CPUs

#316

Post by fortran77 »

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…

So zealous to defend Apple that you didn’t check Firefox and Chrome before posting?

Re: New speculative attacks on Apple CPUs

#317

Post by brookst »

fsflover wrote: post #294
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…

> I'm not surprised to see this come back to bite them if after like 7 years Apple still hasn't adopted the only strong defense. So the Apple's argument that iOS can't have alternative browsers for security is a lie.

Strange claim.

Security isn’t a one-bit thing where you’re either perfectly secure or not. If someone breaks into your house through a window and steals your stuff, that does not make it a lie to claim that locking your front door is more secure.

In any event, Apple’s claim isn’t entirely true. It’s also not entirely false.

Browsers absolutely require JIT to be remotely performant. Giving third parties JIT on iOS would decrease security. And also we know Apple’s fetish for tight platform control, so it’s not like they’re working hard to find a way to do secure JIT for 3P.

But a security flaw in Safari’s process isolation has exactly zero bearing on the claim that giving third party apps JIT has security implications. That’s a very strange claim to make.

Security doesn’t lend itself to these dramatic pronouncements. There’s always multiple “except if” layers.

Re: New speculative attacks on Apple CPUs

#318

Post by fsflover »

brookst wrote: post #317
fsflover wrote: post #294

Earlier quoted context omitted.

> I'm not surprised to see this come back to bite them if after like 7 years Apple still hasn't adopted the only strong defense. So the Apple's argument that iOS can't have alternative browsers for security is a lie.

Strange claim. Security isn’t a one-bit thing where you’re either perfectly secure or not. If someone breaks into your house through a window and steals your stuff, that does not make it a lie to claim that locking your front door is more secure. In any event, Apple’s claim isn’t entirely true. It’s also not entirely false. Browsers absolutely require JIT to be remotely performant. Giving third parties JIT on iOS wou…

The alternative browsers have the required site isolation but aren't allowed. There's no fix for Safari and you must use it. I think it's very clearly decreasing the users' security.

Re: New speculative attacks on Apple CPUs

#319

Post by tails4e »

lxgr wrote: post #185
zamalek wrote: post #182

Earlier quoted context omitted.

The point of my rather facetious comment is that IPC a well known thing (I struggle to even call it "tech") that has been around for 30-40 years. I don't understand why Apple needs people to make excuses for them, but this excuse would render Apple vastly more incompetent than neglecting to separate browser tabs in 2025.

Browsers are incredibly complex, and moving them to an IPC model is not easy. Essentially, you need to ensure "same process like", performant JavaScript interoperability in some cases, often (but not always) due to backwards compatibility. Firefox has shared a lot about their efforts in moving there. If you're curious, there are a lot of blog posts and internal design docs under their project name "Project Fission".…

How often do tabs really need to communicate, and when they do, does it really need to be as fast as possible. I would say slower and secure would be a better design philosophy, especially as tab interaction is generally rare, and low bandwidth

Re: New speculative attacks on Apple CPUs

#320

Post by tholdem »

hashstring wrote: post #223
prmoustache wrote: post #150

Earlier quoted context omitted.

Then don't use an iPhone until it is patched.

What about turn JS off on your favourite iOS browser?

No need to turn JS off. Turn on Lockdown mode which disables Javascript JIT and WASM, which might be enough
Post reply on HN