5 ms·

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.

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 https://bearssl.org/ctmul.html

rwmj 7y ago
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.
- ncmncm 7y ago
  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.
  - rwmj 7y ago
    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.
0xcde4c3db 7y ago
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.
- anoncake 7y ago
  Couldn't this be solved by having constant-time and regular multiplication instructions?
  - 0xcde4c3db 7y ago
    Sure, but the constant-time instructions would presumably be defined in an extension along with other constant-time or crypto-optimized instructions.
  - justincormack 7y ago
    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.

rwmj 7y ago

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.

ncmncm 7y ago
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.
- rwmj 7y ago
  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.

0xcde4c3db 7y ago

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.

anoncake 7y ago
Couldn't this be solved by having constant-time and regular multiplication instructions?
- 0xcde4c3db 7y ago
  Sure, but the constant-time instructions would presumably be defined in an extension along with other constant-time or crypto-optimized instructions.
- justincormack 7y ago
  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.