Should Zba, Zbb, and Zbs instructions be included in Zkt?
topperc opened this issue · comments
Compilers can easily autogenerate many of the instructions in these extensions. Especially zext.h, sext.b, sext.w, max(u), min(u) from Zbb and all of Zba and Zbs.
LLVM can't currently pattern match orc.b, but it can be used with a builtin function.
Not sure if we should include clz, ctz, and cpop. Compilers can pattern match them from specific idioms or builtins.
Or is the implication that if you write crypto code you need to turn off these extensions so the compiler won't use them?
Should Zba, Zbb, and Zbs instructions be included in Zkt?
The Zkt spec is ratified (IIUC), so I don't think its contents can change at this point. It would be a new extension.
Or is the implication that if you write crypto code you need to turn off these extensions so the compiler won't use them?
Some libraries like OpenSSL require certain routines written in (or very close to) assembly, to avoid the risk of a compiler introducing side-channels. However, I don't know how widespread this practice is: for example, ipp-crypto seems to have a lot of C+intrinsics code.
Another risk (which you pointed out to me in private communication) is with the new compressed instructions (Zc* extensions). For example, while mul is in Zkt, its compressed form c.mul is not, since it was introduced subsequently in Zcb. So assembly programmers should probably future-proof their codes by using option norvc, even when they might not think it's necessary.
I think some of them should be included, since they really help to accelerate some operations.
But as @nick-knight said, the list may be immutable since Zkt is ratified. Though I find one commit that added more instructions to Zkt list: c.srli, c.srai, and c.slli are Zkt instructions in RV64, and a new version Scalar Cryptography v1.0.1 released.
I don't know if Zkt should be like other extensions (no change after ratified), since it adds no new instruction but a constraint on hardware implementation. We need to discuss this in more details.
I think some of them should be included, since they really help to accelerate some operations.
But as @nick-knight said, the list may be immutable since Zkt is ratified. Though I find one commit that added more instructions to Zkt list: c.srli, c.srai, and c.slli are Zkt instructions in RV64, and a new version Scalar Cryptography v1.0.1 released.
That was correcting a mistake that they were only marked for RV32. I think it was an editing mistake in an earlier revision and not an intentional omission.
That was correcting a mistake that they were only marked for RV32. I think it was an editing mistake in an earlier revision and not an intentional omission.
Yeah, you are right.
The Zkt spec says:
Currently, the scope of this document is within scalar RV32/RV64 processors. Vector cryptography instructions (and appropriate vector support instructions) will be added later, as will other security-related functions that wish to assert leakage-free execution latency properties.
So maybe we can add more instructions in the future?
It is certainly possible to define other sets of instructions with data-independent execution latency. A standard solution should probably begin with a proposal within the Security HC (security@lists.riscv.org).
Thanks for the suggestion, Craig.
As others have noted, Zkt was defined in the Scalar Crypto specification, which was ratified in early '22, and cannot be changed.
The instructions in the Zkt list were those that were likely to manipulate secret information in the implementation of common cryptographic algorithms. Of course, a compiler is free to chose any instructions on cryptographic code. It is the coder/user's responsibility to ensure that the compiled code does not allow secret information to be exposed from instructions other than those covered by Zkt.
The Vector Crypto Crypto extension, which is frozen and has completed public review, has a more extensive list of instructions in Zvkt.