New speculative attacks on Apple CPUs

How these attacks differ from Spectre/Meltdown

• Several commenters stress these are still speculative side‑channel attacks, not “true” remote code execution: the attacker gets speculative compute on mispredicted data plus a side channel, not persistent control.
• Others argue they are “worse” than typical Spectre variants because the gadget gets hundreds of cycles of speculative execution on attacker-chosen code and data, making exploitation easier than pure cache-probe attacks.
• There is debate over whether calling them “the same flavor” as Spectre understates their impact, but consensus that they fit within the speculative‑execution class opened by Spectre.

Browser, Safari, and site isolation

• A key practical issue is Safari’s lack of full site isolation: different sites (or windows opened via window.open) can share a process and even heaps, letting a malicious page speculatively read another site’s strings.
• Chrome/Firefox are said to have much stronger site isolation (per‑site processes bridged by IPC), though the paper notes corner cases where subdomains can still share a process due to public‑suffix list quirks.
• Multiple commenters say that if Safari had robust site isolation, the SLAP demo would essentially fail; this is highlighted as a textbook “defense‑in‑depth” lesson.

User risk and mitigations

• For typical end‑users, some argue the real‑world risk from speculative browser attacks is “basically zero” and highly targeted; others counter that a reliable JS exploit on even a tiny fraction of machines is enough to motivate attackers.
• On Apple devices, disabling JavaScript, using Lockdown Mode (which turns off JIT/WASM) or avoiding Safari are suggested, but Lockdown alone is reported as insufficient and all iOS browsers share WebKit.
• On desktops, using browsers with strong site isolation and keeping OS/apps updated are the main recommended mitigations; JS-based attacks don’t cross processes.

Apple’s response and disclosure

• Researchers disclosed SLAP in May 2024 and FLOP in September; Apple requested an extended embargo but provided no mitigation timeline, so the work went public well past a 90‑day window.
• Commenters criticize Apple for slow response and historically unfriendly bug‑bounty behavior, though some note hardware‑level fixes and Safari refactors can reasonably take many months.
• Apple’s public statement that the issue poses no “immediate” risk is widely seen as PR minimization, especially given working proofs of concept.

CPU design, performance, and LVPs

• Discussion reiterates that speculative/out‑of‑order execution is central to modern performance; fully avoiding it would make CPUs many times slower.
• Load Value Predictors (LVPs) on newer Apple chips are recognized as a particularly aggressive optimization and a new attack surface; M1 reportedly lacks LAP/LVP and is unaffected by these specific issues but vulnerable to other side channels like GoFetch.
• Some note ARM’s fixed‑length encoding and constant pools make LVPs especially effective there; x86 might still have plenty of predictable loads but makes different trade‑offs.

Broader ecosystem and “exploit marketing”

• Several comments lament the web’s dependence on arbitrary downloaded JavaScript, rising browser/API complexity, and the difficulty of secure in‑process sandboxes (e.g., WASM).
• Others defend the modern “logo + domain + FAQ” style of vulnerability disclosure as necessary to reach non‑experts and drive vendors to act, continuing a trend since Heartbleed.