Comments by "TheEVEInspiration" (@TheEVEInspiration) on "researchers find an unfixable bug in EVERY ARM cpu" video.

  1. I think calling speculative execution "execution in the future" is misleading as it conveys they idea of a "front-running thread", which is a very distinct and different thing. The processor simply runs a program and if it needs to make a branch/turn and does not know which way to go, it speculates. To keep a proper program state, this speculative execution cannot do certain things, but once the speculation is confirmed to be correct, the accumulated speculated results can be committed. From the processors perspective running the program, it's just execution current code, just of a speculated branch. There is of course a lagging program-state that represents the validated non-speculative outcomes. It can restart from this state when the speculated code turned out to be the wrong code and resume with the correct code instead. A processor is thus not "executing future code". It might run the wrong code and discard the results, but it's not running ahead of the actual program. That is a lot less mystic and magical to me.
    3
  2.  @HerrNilssonOmJagFarBe  Interesting, that is just changing data out after a few tries, so simple.
    2
  3. What bypasses security here is not timing, which is just a final measurement. It is having the branch predictor consistently execute a never taken branch where the dereferenced pointer comparison resides! This means that somehow they manipulate the branch predictor (or the branch predictor is very stupid and makes the same misprediction over and over).
    1
  4. This issue here is that there is no cache fill happening for the speculated code, which can be detected later on. And as the wrongly speculated generates no error, they can keep trying with new tags until they found the correct one. For me the real question is how they consistently fool the branch predictor to speculatively execute code for a branch never taken! Because that is what bypasses the security here. I would not call this a timing attack, but a branch algorithm attack.
    1