Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

New CPU microcode is enough, though at a performance price. On pre-Zen AMD there is also a chicken bit to disable indirect branch prediction. (It feels good to be finally able to speak about this freely!!!)

I don't know for which processors Intel and AMD plan to release microcode updates.



> New CPU microcode is enough

What would that entail? Disabling speculation completely? Disabling memory accesses during speculation?


Disabling indirect branch prediction (and thus speculation after indirect branches) while in kernel mode, or flushing the indirect branch predictor on kernel mode entry. Both need OS support in addition to the microcode, but the change is less invasive than PTI.


That only fixes one variant of Spectre, and only for code running in kernel mode.

The "out of bounds" Spectre variant is still feasible.

Also: What about hyperthreads? It seems to be many people's assumption that the BTB is shared within a physical core.


The out of bounds variant is fixable in the OS, just add a fence instruction between the check and the load.

For code running in user mode, you flush the branch predictor on each context switch---again, new microcode + patched OS.

Hyperthreads are tricky. Those are not yet fixed by microcode AIUI, and in the future you may want a usermode program to say "I don't want indirect branch prediction because I am afraid of what the other hyperthread might do to me". That would require some new system call (like a new prctl on Linux) or something like that.


Great. Now we just have to think of new attacks using the same general idea to slow down all computers by yet another 10% :p


Wouldn't that be a serious performance hit?


It is. Same ballpark as PTI on microbenchmarks, but a little better on macrobenchmarks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: