RISC-V support for the SHA256

[marcfedorow]

No description provided.

[paulidale]

LGTM

[t8m]

I know we already approved and merged the SHA-512 support. My question is - for other architectures that add new instructions for algorithm acceleration or any other extra instruction sets we usually support building "full featured" assembler code which contains fallback code paths for CPUs which do not support these instructions. Do these RISC-V PRs effectively make the asm build for RISC-V depending on these special instructions being supported?

Please note I do not know almost anything about RISC-V so it is possible that these instructions are widely available and for the rest building with no-asm is sufficient.

[marcfedorow]

@t8m
I do not think that I can produce efficient assembler code like this.
However sha* instructions are not the only that increase performance.
I did not add inline assembler for instructions that can be automatically emitted by the compiler. They are mostly bit manipulation instructions (such as rotations, zero counting, etc).
If riscv-bitmanip instructions are present, compiler should emit them regardless of presence of zkn instructions.

To some point compiler generates more or less efficient code depending on what exact subset is supported. My patches should help it in that cases where it can not generate the most efficient code by itself.

Sorry if I misunderstood your question.

[t8m]

I try to ask differently - Other asm implementations for different architectures (such as x86, arm, ppc, or s390x) do runtime selection of the codepath (and thus extra instructions) used. So the code can be built once and run on different CPU models with different extra instructions (AVX2, SSSE3,....). Your patches do not do that, if I understand them correctly. They are just build-time and once you build so the instructions are used you cannot use the binaries on CPUs which do not support these sha512 or sha256 instructions.
I am saying that just for consideration.

[marcfedorow]

Yes, you understand my patches correctly.
E.g. this code compiled with -march=rv64izkn will fail with cause 2 (illegal instruction) if run on hardware with no ZKN-extension.

The problem is: RISC-V currently has no consensus about the discovery mechanism. Previously it should be done by checking the machine-ISA register. Currently, both bit-manipulation and cryptographic extensions marked their MISA bits as deprecated (they now should be hard-wired to zero).

Here is the quote from the pre-release version:
The misa.K bit is no longer used to identify the scalar cryptography extension. Feature detection of scalar cryptography extensions will be done using the work-in-progress discovery mechanisms for RISC-V.
This applies to the release version too.

So now there is no consensual adequate discovery mechanism at this exact moment.
Previously I could use something like

shl x1 1 10 # reg1 = 1 << ('K' - 'A')
csrr x2 misa # read a control/status register w/ info about supported extensions 
and x1 x1 x2  # reg1 &= misa
beqz x1 fallback # if (!reg1) goto: fallback

But now it is impossible.

The only way it is possible to provide run-time fallbacks is to execute some instruction and then to catch an exception.
Probably another way will be developed -- if so (or if traps become the recommended way to check the extension presence) I will probably implement assembler with run-time fallbacks.
I do not think that it should be done now because the discovery mechanism is not frozen yet.

[t8m]

OK, thanks for the explanation. I think I can approve this now.

[paulidale]

The only way it is possible to provide run-time fallbacks is to execute some instruction and then to catch an exception.

Some platforms do exactly this. It's hideous.

[t8m]

Some platforms do exactly this. It's hideous.

Yeah that approach is causing multiple problems, let's not do it here.

[openssl-machine]

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually.

[kroeckx]

At least one approach we use on some platforms, is that the OS can provide that information. On linux this would be using getauxval().

[paulidale]

Good point @kroeckx

[t8m]

Merged to master. Thanks for the contribution.