7 ms·

They don't explicitly say. Is part of this a microcode update?

userbinator 9y ago
If it is (very likely, because only Intel can issue them thus far), they probably figured out how to turn off the branch predictor. The performance drop will still be there, but better than the "recompile everything to not use indirect jump and call instructions"[1][2], at any rate. [1] https://news.ycombinator.com/item?id=16066968 https://news.ycombinator.com/item?id=16066968 [2] https://news.ycombinator.com/item?id=16070050 https://news.ycombinator.com/item?id=16070050
- mozumder 9y ago
  If it's a timing attack, they probably don't need to fully turn it off, but turn it off and on randomly every now and then..
  - Skunkleton 9y ago
    That wont do it. The true data will still bias the results.
    - mozumder 9y ago
      So, Google and Apple ended up reducing precision on their web browser timing APIs to mitigate this attack.
      - Skunkleton 9y ago
        Exactly. They never expose a timer of sufficient resolution. That is different from _sometimes_ exposing a timer of sufficient resolution.
    - emn13 9y ago
      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.
      - Skunkleton 9y ago
        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?
        emn13 9y ago
        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.
        Skunkleton 9y ago
        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).
  - IncRnd 9y ago
    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.
    - mozumder 9y ago
      Makes sense. But man these attacks really do need lots and lots of CPU just to extract one bit of data.
- bpye 9y ago
  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-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub https://docs.google.com/document/u/2/d/e/2PACX-1vSMrwkaoSUBA...
- tomxor 9y ago
  > 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.
  - tomxor 9y ago
    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.
- earenndil 9y ago
  > 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.
  - userbinator 9y ago
    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/ http://inertiawar.com/microcode/
dzdt 9y ago
Cloud vendor Scaleway reports that Intel has promised them a microcode update: https://blog.online.net/2018/01/03/important-note-about-the-security-flaw-impacting-arm-intel-hardware/ https://blog.online.net/2018/01/03/important-note-about-the-... "According to the latest update from Intel, a microcode is required to completely fix the bug. The microcode release date is, at this time, scheduled for an undisclosed confidential unacceptable late date"
mtgx 9y ago
They say in the post that the updates are distributed by system makers.

If it is (very likely, because only Intel can issue them thus far), they probably figured out how to turn off the branch predictor. The performance drop will still be there, but better than the "recompile everything to not use indirect jump and call instructions"[1][2], at any rate. [1] https://news.ycombinator.com/item?id=16066968 https://news.ycombinator.com/item?id=16066968 [2] https://news.ycombinator.com/item?id=16070050 https://news.ycombinator.com/item?id=16070050

mozumder 9y ago
If it's a timing attack, they probably don't need to fully turn it off, but turn it off and on randomly every now and then..
- Skunkleton 9y ago
  That wont do it. The true data will still bias the results.
  - mozumder 9y ago
    So, Google and Apple ended up reducing precision on their web browser timing APIs to mitigate this attack.
    - Skunkleton 9y ago
      Exactly. They never expose a timer of sufficient resolution. That is different from _sometimes_ exposing a timer of sufficient resolution.
  - emn13 9y ago
    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.
    - Skunkleton 9y ago
      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?
      - emn13 9y ago
        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.
        Skunkleton 9y ago
        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).
- IncRnd 9y ago
  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.
  - mozumder 9y ago
    Makes sense. But man these attacks really do need lots and lots of CPU just to extract one bit of data.
bpye 9y ago
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-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub https://docs.google.com/document/u/2/d/e/2PACX-1vSMrwkaoSUBA...
tomxor 9y ago
> 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.
- tomxor 9y ago
  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.
earenndil 9y ago
> 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.
- userbinator 9y ago
  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/ http://inertiawar.com/microcode/

dzdt 9y ago

Cloud vendor Scaleway reports that Intel has promised them a microcode update: https://blog.online.net/2018/01/03/important-note-about-the-security-flaw-impacting-arm-intel-hardware/ https://blog.online.net/2018/01/03/important-note-about-the-... "According to the latest update from Intel, a microcode is required to completely fix the bug. The microcode release date is, at this time, scheduled for an undisclosed confidential unacceptable late date"

mtgx 9y ago

They say in the post that the updates are distributed by system makers.