....Apple are super secure so people, who don't understand, keep telling me.
Each tab (or process) in Private Browsing Mode has its own state when it comes to cookies and other things (unlike with Chromium and Gecko browsers). If Safari didn't act the way it currently does, websites opening windows like would result in the user being "logged out" when they shouldn't be; and to change the behaviour of the engine to act more like Chromium/Gecko would be a privacy downgrade for people who always browse with full cookie/preference/state isolation between all tabs (except those which obviously need to inherit state for popups to remain logged in). Thus, a proper fix for this issue isn't exactly trivial, especially as other browsing engines still can't have their cake and eat it too when it comes to offering similar functionality.
Love this bit. They essentially create their own timer by running a yardstick thread. Exploiting a time-based side-channel without access to a timer just emphasises how difficult mitigating these kind of attacks is.
Nice work overall.
It's a good technique, but it dates back in this specific form at least as far as the original SPECTRE research, and in general at least as far back as Paul Kocher's timing attacks against RSA and DH in the mid-1990s, if memory serves.
Before it can even begin doing anything. Even if you stay on the same page for that long, you're gonna notice your phone getting warm when it is running at 100% CPU the whole time.
Speculative execution seems to be a shambles on every CPU, they all have multiple exploits and new ones pop up even if old ones are mitigated. I wonder if it is possible for speculative execution to ever be secure?
It is, but there is a cost, and that cost is not low.
I was in microprocessor validation 1996-2006. Basically, I started when spec-X came out.
The problem is endemic to caching with spec-X in that generation of processors.
One solution that comes to mind is to mark cache lines (at ALL levels) as speculative until the thread of execution that fetched them goes non-speculative. Until that time, any other thread needing the data will have to refetch. Of course, you cannot actually put this speculative in a cache without ejecting something which is already there, which means that you either need an orphan buffer or a prefetch buffer for all caches. (This includes TLBs, ERATs, and whatever else is lying around). My confidence that these would not break the first several times around is...low.
The other option would be to use some sort of L0 for the speculative loads, and only write back to the higher levels when the load goes non-speculative. That sounds a lot less complicated, but would completely upend what I (highly inaccurately) understand of cache architecture.
Since I was already out of the business for a decade when Specter was announced, I've not closely followed developments. But I cannot imagine a hardware fix that was NOT trumpeted by whoever managed it.
We've already had Intel and AMD trumpet their fixes, which were later proved inadequate as ways around them or different but similar avenues of attack discovered.
Even if you believed you'd fully cured the issue you probably don't want to make such a claim in public because it just makes you look dumb when you're proven wrong. Heck even if you fix speculative execution there are other avenues of hardware attack or weaknesses (think Intel ME) that they'd best act like the software guys do and just assume the next hole discovered is just around the corner. No one would ever claim that they had a 100% "secure" operating system because they know that claim wouldn't last a holiday weekend.
side channels are hardware-based
This is incorrect. There are many software side-channel vulnerabilities, and in cryptography in particular there's a long history of software side-channel attacks that completely break security. SSL v1 was broken with a side-channel attack. Others include Kocher's timing side-channel attacks against RSA and DH, and the various forms of the Bleichenbacher attacks. Side channels are the whole reason many cryptographic operations have to be implemented with constant-time arithmetic to avoid leaking information; these are practical attacks which have been demonstrated in real-world use cases.
Microarchitectural side channels such as SPECTRE are hardware-based, as are TEMPEST-style EMF side channels, and those perennial attacks against things like status LEDs. So are some classes of error-induction attacks like the classic smartcard-in-a-microwave (one of Rivest's, I think). But anything that leaks information can potentially become a side-channel vulnerability, and that most definitely includes software.