I'm excited to see that the RV32 AES instructions now have separate rs1 and rd fields, because the previous version combined them into just rt, which was kind of annoying from an implementation perspective, since you had some register that was both input and output (iirc, unlike any other RV32 instruction previously implemented on that hardware)
A quick summary of what is included for those who don't feel like reading the spec:
- Some miscellaneous bit twiddling instructions (rotate, permute, pack, ...) useful in various crypto schemes.
- AES.
- SHA2 (-256 and -512).
- SM3 and SM4.
- Physical entropy source (with some variants to accommodate low profile variants)
The SM3/4 were unfamiliar to me - apparently it is a hash function & block cipher used in Chinese WiFi variant. Should I just assume this is backdoored?
I'm biased, but the spec is supposed to be very accessible to people without a cryptography background. There's a section on who the intended audience is and what assumptions are made about their background. I'd really recommend it.
> The SM3/4 were unfamiliar to me - apparently it is a hash function & block cipher used in Chinese WiFi variant.
SM3/4 are required for use in certain places in China. RISC-V is popular in China, hence their inclusion in the RISC-V spec. My expectation is that SM3/4 will not likely ever be adopted outside China.
> Physical entropy source (with some variants to accommodate low profile variants)
There are no "variants" of the entropy source. There is one entropy source interface definition which is designed to scale across the many RISC-V implementation profiles. It's very different to x86/RDRAND which lots of people are used to.
Pretty much every instruction that doesn't start with the name of some known crypto algorithm (and maybe some that do) are useful for general-purpose stuff. I've had a good deal of success making Intel's GFNI do "weird off-label things" (bit-matrix transpose and a lot of the missing byte shift/rotate operations just scratches the surface). CLMUL is a good one for all sorts of things, as it can be used for XOR-parallel-prefix (we used it to detect quote pairs in simdjson).
I don't know whether I resent crypto because it gets the cool instructions at low latency because it's so important, or whether I love it due to the fact that even the "leavings at the crypto table" are computationally useful.
Stockholm syndrome, CPU makers have been needlessly starving us of highly useful bit manipulation and finite field operations ... so you're very thankful for what you get. :)
Base RISCV even lacks CLZ/popcount -- so it's a step backward from other popular architectures.
That said the stuff in bitmanip and crypto looks pretty good, so if they actually end up in chips that will be nice. On the other hand it's not clear how much awesome code will get written really exploiting them when they aren't everywhere-- which is probably why we're in this situation to begin with.
It means that each instruction reads no more than two general purpose registers (i.e. inputs), and writes at most one. When you build CPUs, register files are expensive components, and the more parallel accesses to them you need, the more expensive they become. RISC architectures generally rely on only reading two operands and writing only one result. Sometimes this rule is broken, but RISC-V tries to stick to it unless there's an extremely good reason.
ausbin|4 years ago
I'm excited to see that the RV32 AES instructions now have separate rs1 and rd fields, because the previous version combined them into just rt, which was kind of annoying from an implementation perspective, since you had some register that was both input and output (iirc, unlike any other RV32 instruction previously implemented on that hardware)
Narishma|4 years ago
progbits|4 years ago
bem94|4 years ago
I'm biased, but the spec is supposed to be very accessible to people without a cryptography background. There's a section on who the intended audience is and what assumptions are made about their background. I'd really recommend it.
> The SM3/4 were unfamiliar to me - apparently it is a hash function & block cipher used in Chinese WiFi variant.
SM3/4 are required for use in certain places in China. RISC-V is popular in China, hence their inclusion in the RISC-V spec. My expectation is that SM3/4 will not likely ever be adopted outside China.
> Physical entropy source (with some variants to accommodate low profile variants)
There are no "variants" of the entropy source. There is one entropy source interface definition which is designed to scale across the many RISC-V implementation profiles. It's very different to x86/RDRAND which lots of people are used to.
glangdale|4 years ago
I don't know whether I resent crypto because it gets the cool instructions at low latency because it's so important, or whether I love it due to the fact that even the "leavings at the crypto table" are computationally useful.
nullc|4 years ago
Base RISCV even lacks CLZ/popcount -- so it's a step backward from other popular architectures.
That said the stuff in bitmanip and crypto looks pretty good, so if they actually end up in chips that will be nice. On the other hand it's not clear how much awesome code will get written really exploiting them when they aren't everywhere-- which is probably why we're in this situation to begin with.
pw98745bnt|4 years ago
bem94|4 years ago