[Cryptography] RISC-V branch predicting

John Levine johnl at iecc.com
Tue Feb 6 18:53:23 EST 2018


In article <8FAA204A-D24D-48B4-AFD3-A7692C416846 at me.com> you write:
>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? 

Back when VLIW was young, the Multiflow compiler could use runtime
stats from previous runs when recompiling.  Since VLIW is all about
speculative execution, it made a lot of difference.  But in practice
people didn't like it, didn't want to do it, and voted with their feet
to move to machines where you didn't have to do that.

It is my impression that it is hard enough to get adequate test cases
to test the correctness of libraries.  If we were supposed to get test
cases that weren't just minimal exercises of the code but realistic
uses, how likely is it that people would really do that?  For
libraries doing heavy computation with runs of hours or days, sure,
but how about something like crypto libraries?  Maybe certificate
handshakes and channel encryption take enough time to be worth
profiling and optimizing, but who's going to collect the data and pay
people to do it?

Dismally,
John



More information about the cryptography mailing list