New speculative attacks on Apple CPUs

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 vendors largely agreed that the only strong defense was complete process isolation.

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.

Forcing every website to adapt to a browser update is completely infeasible.

> I can't imagine there are many sites passing significant amounts of data through this

This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).

Safari definitely does use site isolation (if you check "Activity Monitor", you'll find Safari processes named after the sites they're displaying) in almost all cases.

window.open, in some constellations, is an exception, because the opening and opened sites have an explicit communication facility available to them, unless at least one of the two explicitly opts out of it. As far as I'm aware, Safari also correctly implements that opt-out.

The only thing that Chrome and Firefox seem to be doing on top of that, as far as I understand, is to actually enforce process-per-site even for sites from the same "browsing context group" (i.e. all that can hold programmatic references to each other, e.g. via window.opener), which requires using IPC.

Right, in what sane world would the website determine operating system process semantics? What next, syscalls?

Have you noticed how often people complain Chrome uses too much memory?

Sorry, I was imprecise in my original post: It's definitely possible to isolate even sites in the same browsing context group, but it requires more work that Safari apparently just hasn't got around to yet.

It's not unreasonable to set a different header value for the login page only, where it should be safe because no external user data is being rendered.

Sites can also opt into the same behavior by setting the rel="noopener" or alternatively target="_blank" attributes on outgoing links (i.e. <a> tags).

And yes, something like a webmail site should definitely be setting the header, or at lest these attributes for outbound content links.

Yes, and that’s what Firefox and Chrome are already doing.

If the costs are high enough you’re basically reimplementing multi-process isolation from first principles.

"trivial" how do you figure? Remember these exploits bypass your own code's conditionals over a shockingly far duration. Unless you just mean for incredibly restrictive usages such as eBPF?

possible absent any performance concerns at all, yeah sure

What I know as a developer is web security is really hard. Last week there was a DOM clobbering gadget deep in my TypeScript world and I really didn't have the energy to understand who wants to clobber my DOM and why they need a gadget. I want to build stuff and what worries me is this stuff is just simply not foreseeable.

To be fair, this is (relatively, compared to the age of the web) new behavior though.

Even Chrome, which pioneered the "tab per process" model, didn't isolate same browsing group context sites for a long time, and still shares processes on Android as a resource optimization: https://chromium.googlesource.com/chromium/src/+/main/docs/p...

Firefox only released their "Project Fission" in 2021, i.e. three years after Spectre.

Apple devices use 16kB pages.

macOS/iOS don’t

That might be their point. As the OP quoted

> any virtual address below 0x100, 000, 000 is invalid.

That kinda suggests that all 32bit addresses are inherently invalid on 64bit MacOS

Multithreading may be an obscure feature to you but runtime developers get requests for it all the time. SAB becoming widely available was definitely delayed.

Have you considered that it might be difficult?

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 together. The threat just isn't there.

For regular end-user desktop machines, the mitigations only decrease performance for no real benefit. Spectre is a highly targeted attack, it's not something you can just point at any random machine to retrieve all their bank passwords or whatever.

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 I place an online order?

Disabling SMT alone isn’t enough to mitigate CPU vulnerabilities. For full protection against issues like L1TF or MDS, you must both enable the relevant mitigations and disable SMT. Mitigations defend against attacks where an attacker executes on the same core after the victim, while disabling SMT protects against scenarios where the attacker runs concurrently with the victim.

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

If just visiting a webpage with some JS will let them do ACE on even 0.1% of visitors, hackers are probably still motivated enough to try it. But I vaguely remember these kinds of vulns can be patched in-browser for a perf hit instead of taking the hit system-wide, which sounds like an ok compromise.

Edit: Arbitrary memory access, not ACE

It's a tragedy that so many websites insist on having the ability to run random downloaded code on our systems to do basic things like displaying simple text and images. Things browsers are capable of with nothing but HTML. Google refuses to even show search results, a bunch of literal hyperlinks, without javascript being enabled.

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

my specific use case where I see significant performance improvement is image segmentation pipelines (which involve opencv-style image processing and AI inference). YMMV depending on your CPU I suppose.

Video editing maybe? Which is not going to involve running untrusted code.

Keep in mind that getting meltdown to work might be very difficult depending on your setup. I wouldn't have been able to at least when starting out my teacher didn't provide us with targetable hardware.

A spectre (particularly RSB-based ones) are nice to start out with imo.

GLitch was a Rowhammer browser based attack [1]. It's not Spectre/Meltdown but still, for a while people thought it couldn't be done.

[1] https://www.vusec.net/projects/glitch/

The language seems to argue otherwise: SLAP "allows the adversary to jump the LAP to the target webpage's string and trick the CPU into operating on it" and FLOP "allows us to run a function with the wrong arguments". That's absolutely not mere data exfiltration.

Now, maybe this is because of a trampoline based on pre-existing Safari bugs and not the CPU misfeature itself. Again, the details are slim.

But "the same flavor of vulerability" seems to be a mischaracterization.

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.

Now wait until the zoomers come along and take the lead on these products. They grew up with iPads and no file system. It’s going to be chaos!

Yes and it's very slow as a result. In-order cores without speculative execution can't be fast. Not unless you have no memory and only operate out of something equivalent to L1 cache.

Memory is slow. Insanely slow (compared to the CPU). You can process stupid fast if your entire working set can fit in a 2KB L1 cache, but the second you touch memory you're hosed. You can't hide memory latency without out-of-order execution and/or SMT. You fundamentally need to be parallel to hide latency. CPUs do it with out-of-order and speculative execution. GPUs do it by being stupidly parallel and running something like 32-64 way SMT (huge simplification). Many high-performance CPUs do all of these things.

Instruction level parallelism is simply not optional with the DRAM latency we have.