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

321–330 of 365 posts

Re: New speculative attacks on Apple CPUs

#321

Post by eigenform »

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…

> 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 be half-attributed to authors from Intel PARL!):

> [...] we first study the static load instructions that repeatedly fetch the same value from the same load address across the entire workload trace. We call such a load global-stable.

> [..] We make two key observations. First, 34.2% of all dynamic loads are global-stable. Second, the fraction of global-stable loads are much higher in Client, Enterprise, and Server work-loads as compared to SPEC CPU 2017 workloads.

[^1]: https://arxiv.org/pdf/2406.18786

Re: New speculative attacks on Apple CPUs

#322

Post by worthless-trash »

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.

Are you really surprised, eventually the apple distortion field starts to wain around the edges but by then people have moved on to the new shiny.

Re: New speculative attacks on Apple CPUs

#324

Post by brookst »

fsflover wrote: post #318
brookst wrote: post #317

Earlier quoted context omitted.

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.

Binary thinking is unhealthy.

Alternative browsers would introduce other security concerns, including JIT. It’s debatable whether that would be a net security gain or loss, but it’s silly to just pretend it’s not a thing.

Security as the product of multiple risks.

Discovering a new risk does not mean all of the other ones evaporate and all decision making should be made solely with this one factor in mind.

Re: New speculative attacks on Apple CPUs

#325

Post by trompetenaccoun »

layer8 wrote: post #156
daneel_w wrote: post #50

Apple released minor-version updates to both macOS and iOS the past few days, both containing several security fixes. Has anyone been able to confirm if they address these exploits?

They haven’t yet. From https://www.bleepingcomputer.com/news/security/new-apple-cpu... : Apple acknowledged the shared proof-of-concept and stated it plans to address the issues. However, at the time of writing, the flaws remain unmitigated. "We want to thank the researchers for their collaboration as this proof of concept advances our understanding of these types of threats," Apple told BleepingComputer. "Based on o…

It's crazy that they were informed about this months ago and still have not fixed it yet. They're going to have to now that it's public but why would that pressure even be needed. I naively assumed if Apple still gets one thing right it's security updates. This is disappointing and concerning.

Re: New speculative attacks on Apple CPUs

#326

Post by fsflover »

brookst wrote: post #324
fsflover wrote: post #318

Earlier quoted context omitted.

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.

Binary thinking is unhealthy. Alternative browsers would introduce other security concerns, including JIT. It’s debatable whether that would be a net security gain or loss, but it’s silly to just pretend it’s not a thing. Security as the product of multiple risks. Discovering a new risk does not mean all of the other ones evaporate and all decision making should be made solely with this one factor in mind.

"Decreasing the security" is not binary thinking. It's just a fact today. Also, ability to run software doesn't make you less secure. I never saw any real proof of that. It's the opposite: Competition between different browsers forces them to increase the security, and it doesn't work for Safari on iOS.

Re: New speculative attacks on Apple CPUs

#327

Post by adrian_b »

eigenform wrote: post #321
adrian_b wrote: post #306

Earlier quoted context omitted.

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…

> 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 CPU core may have 10 times to 20 times more available registers, which could be used to store the global-stable values.

This is one of the reasons why Intel wants to double the number of general-purpose directly addressable registers from 16 to 32 in the future Diamond Rapids CPU (the APX ISA extension).

In other cases the code is not well structured and it tests repeatedly some configuration options, which could be avoided by a proper partitioning of the code paths, where slow tests would be avoided and the execution time would be reduced, even at the price of a slight code size expansion (similarly to the effect of function inlining or loop unrolling).

Sometimes the use of such global-stable values could have been avoided even by moving at compile time the evaluation of some expressions, possibly combined with dynamic loading of some executable objects that had been compiled for different configurations.

So I have seen many cases of such global-stable values being used, even for CPU ISAs that do not force their use, but almost none of them were justified. Improving such programs at programming time or at compile time would have resulted in greater performance improvements, which would have been obtained with less energy consumption, than implementing a load-value predictor in the CPU.

Re: New speculative attacks on Apple CPUs

#328

Post by hansvm »

daneel_w wrote: post #157
School-Cotton wrote: post #90

Earlier quoted context omitted.

In my experience SMT is still faster for most workloads even with the mitigations.

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…

It usually speeds up basically everything parallelizable that looks kind of like a parser, lexer, tokenizer, .... Unless somebody goes out of their way to design a format with fewer data dependencies, those workloads are crippled on modern CPUs. That includes (de)compression routines, compilers, protobuf parsing, ....

The only real constraint is that you can actually leverage multiple threads. For protos as an example, that requires a modified version of the format with checkpoints or similar (which nobody does) or having many to work on concurrently (very common in webservers or whatever).

Re: New speculative attacks on Apple CPUs

#329

Post by philodeon »

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

Given that the researchers published working exploits that you can modify for your own use, it’s PR.

Re: New speculative attacks on Apple CPUs

#330

Post by raxxorraxor »

brookst wrote: post #324
fsflover wrote: post #318

Earlier quoted context omitted.

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.

Binary thinking is unhealthy. Alternative browsers would introduce other security concerns, including JIT. It’s debatable whether that would be a net security gain or loss, but it’s silly to just pretend it’s not a thing. Security as the product of multiple risks. Discovering a new risk does not mean all of the other ones evaporate and all decision making should be made solely with this one factor in mind.

I think a detached and distanced perspective must come to the conclusion that vendor lock-in isn't healthy. For security, performance or flexibility it tends to fall short sooner or later.

One could also talk about the relevance of a speculative attack that hasn't been abused for years. There can be multiple reasons for that, but we shouldn't just ignore the main design motivation of Apple here. That would be frivolous and that excludes serious security discussions.

Post reply on HN