[aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic

[Andrew Haley]

On 31/08/2020 07:50, Yangfei (Felix) wrote:
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8252204
>     Webrev: http://cr.openjdk.java.net/~fyang/8252204/webrev.00/
>
>     This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
>     Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
>         https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-cecore.S?h=v5.4.52
>    Trivial adaptation in SHA3. implCompress is needed for the purpose
>    of adding the intrinsic.  For SHA3, we need to pass one extra
>    parameter "digestLength" to the stub for the calculation of block
>    size.  "digestLength" is also used in for the EOR loop before
>    keccak to differentiate different SHA3 variants.
>
>    We added jtreg tests for SHA3 and used QEMU system emulator
>    which supports SHA3 instructions to test the functionality.
>    Patch passed jtreg tier1-3 tests with QEMU system emulator.
>    Also verified with jtreg tier1-3 tests without SHA3 instructions
>    on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that
>    there's no regression.
>
>    We used one existing JMH test for performance test:
>    test/micro/org/openjdk/bench/java/security/MessageDigests.java
>    We measured the performance benefit with an aarch64
>    cycle-accurate simulator.
>    Patch delivers 20% - 40% performance improvement depending on
>    specific SHA3 digest length and size of the message.
>    For now, this feature will not be enabled automatically for
>    aarch64.  We can auto-enable this when it is fully tested on
>    real hardware.
>    But for the above testing purposes, this is auto-enabled when
>    the corresponding hardware feature is detected.
>
>    Comments?

This looks like a direct copy of the sha3-cecore.S file.You'll need
Linaro to contribute it.  I don't imagine they'll have any problem
with that: they are OCA signatories

Also, given that we've got the assembly source file, why not just copy
that into OpenJDK? I can't see the point rewriting it into the HotSpot
assembler.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671