[Cryptography] RISC-V branch predicting

Arnold Reinhold agr at me.com
Mon Feb 5 13:20:49 EST 2018


I was looking through the RISC-V User-Level ISA Specification (Volume I, V2.2 https://riscv.org/specifications/) and found the following in the description of the conditional branch instructions (p.17 ff):

“Software should be optimized such that the sequential code path is the most common path, with less-frequently taken code  paths  placed out of line.  Software should also assume that backward branches will be predicted taken and forward branches as not taken, at least the first time they are encountered.  Dynamic predictors should quickly learn any predictable branch behavior.” and

“We  considered but did not include static branch  hints in the instruction encoding. These can reduce the pressure on dynamic predictors, but require more instruction encoding space and software profiling for best results, and can result in poor performance if production runs do not match profiling runs.”

Given the apparently unbounded Spectre security risks presented by current branch predictors, maybe it is time to reconsider the division of labor between clever CPU hardware and the software development tool chain. In most cases the programmer knows which way branches are likely to go, optimizing compilers can make good guesses and profiling tools should be very effective if given realistic data. I suspect that most execution time in software people use these days is spent in libraries that can be highly tuned. Is there any research that says the additional gain from sophisticated hardware branch prediction is significant in practice? Is it significant enough to justify the security problems? 

Given that the RISC-V community has not gone very far in deploying advanced risk prediction logic, maybe simple rubrics such as those suggested in the first paragraph quoted above, along with improvements in the software tool chain, such as maybe branch prediction pragmas and better integrated profiling tools, could result in good performance while avoiding Specte type problems.

Arnold Reinhold


More information about the cryptography mailing list