Seeing Intel's patches on LKML they seem to suggest that retoline is actually preferable over disabling the branch predictor [1]

[1] https://docs.google.com/document/u/2/d/e/2PACX-1vSMrwkaoSUBA...

> they probably figured out how to turn off the branch predictor.

:P I hope the fix is this crude... the performance drop would be hilarious, Apple would probably switch back to PowerPC by the summer.

Note: I was obviously being facetious, but It made me wonder how far back branch prediction goes not being a microarchitecture expert... Surprised to find even the old 68k utilises it! not that they necessarily suffer the same fate through the concept alone of course.

> only Intel can issue them thus far

I wouldn't bet on that lasting, though. This CCC someone essentially reverse-engineered microcode on 5-10 year old amd processors. I wouldn't be surprised if they figured out how to do it on newer processors and intel processors.

Intel's microcode updates are signed by a 2048-bit RSA key and some unknown 160-bit hash function (might be SHA-1, but none one publicly knows) for older models, with newer ones using a 256-bit hash function. Unless there's a very clever exploit, I doubt third-party microcode updates will ever be possible:

http://inertiawar.com/microcode/

That wont do it. The true data will still bias the results.

Even this PoC was limited to 2000 bytes a second; even a little noise may well render the attack largely theoretical - or at least make the attack so slow as to make it feasible to use other (expensive) mitigations only very rarely.

But yeah, it's not a brilliant solution. But it would help.

Even one byte per minute would be enough to cause serious issues. Imagine if some add served up by a torrent site could read information from another tab rendered by the same process?

Not good, but still thousands of times better. And don't forget that you still need to guess where to read from, which better be a very very accurate guess at that rate. Making such an accurate guess is difficult when your runtime is as complex as a browsers, and so even without that extra timing noise no PoC exists (AFAIK?) attacking browsers.

But you know... you're not wrong ;-). I'm just not particularly worried about the likelihood of this attack hitting anything I care about anytime very soon.

Google does have a PoC for spectre that attacks Chrome via Javascript. That said, I am not super worried either. Its not like all my personal data isn't already out there for all to see (Thanks Equifax).

So, Google and Apple ended up reducing precision on their web browser timing APIs to mitigate this attack.

Exactly. They never expose a timer of sufficient resolution. That is different from _sometimes_ exposing a timer of sufficient resolution.

Side-channel timing attacks work on websites by executing MANY similar requests. In a similar way, in this case, while individual requests may not appear to adhere to a timing profile, over time they likely will still be discoverable.

c.f. The random number generator in "The Mythical Man Month" that only guaranteed any one number will be random, not a sequence of numbers.