Hacker News Reader

Comment by beefhash | Hacker News Reader

I really wish it was just one tiny less bit simple. The RISC-V spec doesn't specify that multiplication instructions (if implemented) need to be constant-time. Which means RISC-V cores will need stupid hacks for cryptography like these: https://bearssl.org/ctmul.html

View on HN

A big part of the RISC-V story is the idea that microarchitecture decisions belong to the implementation and not the ISA specification. Specifying that multiplication must be constant-time would effectively be specifying that area-optimized cores aren't allowed to provide the multiplication instructions.

Couldn't this be solved by having constant-time and regular multiplication instructions?

Sure, but the constant-time instructions would presumably be defined in an extension along with other constant-time or crypto-optimized instructions.

Arm 8.4 has a constant time flag that makes most instructions constant time, without changing the instruction set. You could definitely add this to risc-v. Or just make a constant time implementation.

It could be added in the future as a simple extension. (In fact I found at least two proposed crypto extensions with a simple search although neither mentions constant-time ops from a quick scan). There's a considerable penalty for all implementations if every multiply implementation has to be constant time.

That is another problem.

The "optional extensions" have all the useful instructions in them, but typically just a couple of the instructions in each extension would provide most of its value.

So, I don't get popcount because it's in the bitmanip extension along with 10M transistors' worth of clever stuff I don't need. Similarly, each of the other extension sets.

It would be much more useful to define slices through all the defined ones, so you get either the absolute minimum core instructions, or add just the coremost of each extension set, or a more comfortable subset of each, or half of each, spiraling outward as transistor budget grows.

10 million transistors is a tenth of a square millimeter on current nodes, but that aside you really wouldn't want such a complicated system of "sub-extensions" because it would be a nightmare to write software for. Either the software would only work for very specific sub-extension mixes, or would require layers of ifuncs to deal with all combinations of missing sub-extension features.

The current system of fairly granular extensions, a useful base architecture, and profiles defining what extensions are guaranteed for particular application classes (eg "Unix server") is a nice compromise between extensibility and software/distro complexity.

Reply on news.ycombinator.com