8334999: RISC-V: implement AES single block encryption/decryption intrinsics #19960

ArsenyBochkarev · 2024-06-30T14:02:00Z

Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with Zvkned extension enabled the test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8334999: RISC-V: implement AES single block encryption/decryption intrinsics (Sub-task - P4)

Reviewers

Robbin Ehn (@robehn - Reviewer) 🔄 Re-review required (review applies to 02dc4e29)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19960/head:pull/19960
$ git checkout pull/19960

Update a local copy of the PR:
$ git checkout pull/19960
$ git pull https://git.openjdk.org/jdk.git pull/19960/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19960

View PR using the GUI difftool:
$ git pr show -t 19960

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19960.diff

Webrev

Link to Webrev Comment

…rinsics

bridgekeeper · 2024-06-30T14:02:48Z

👋 Welcome back ArsenyBochkarev! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2024-06-30T14:02:57Z

@ArsenyBochkarev This change is no longer ready for integration - check the PR body for details.

openjdk · 2024-06-30T14:03:20Z

@ArsenyBochkarev The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2024-06-30T14:06:53Z

Webrevs

robehn

Thank you, looks good!

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp

ArsenyBochkarev · 2024-07-14T14:57:00Z

As for comparison with the openssl version: first of all, thanks for the sources, @RealFYang! The main difference that I see is that they introduced three different different versions of encryption depending on the key sizes, which allows them to skip a couple of instructions, like when I did vaesem_vv(res, vzero) followed by vxor_vv(res, res, vtemp1). So I thought it'll be more efficient to replace the current version by something openssl-lookalike. The only problem I see is increasing code size a bit. Please let me know if we are not interested in this change for some reason

RealFYang · 2024-07-18T08:26:02Z

As for comparison with the openssl version: first of all, thanks for the sources, @RealFYang! The main difference that I see is that they introduced three different different versions of encryption depending on the key sizes, which allows them to skip a couple of instructions, like when I did vaesem_vv(res, vzero) followed by vxor_vv(res, res, vtemp1). So I thought it'll be more efficient to replace the current version by something openssl-lookalike. The only problem I see is increasing code size a bit. Please let me know if we are not interested in this change for some reason

Does vaesz_vs help in anyway? And what about the generate_aescrypt_decryptBlock? [1]

[1] https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aes-riscv64-zvkned.pl#L451

bridgekeeper · 2024-08-15T12:03:19Z

@ArsenyBochkarev This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

ArsenyBochkarev · 2024-09-08T13:21:15Z

Hello @RealFYang! Sorry for such a late reply.

Does vaesz_vs help in anyway?

As far as I know, the vaesz_vs instruction is just an alias for vxor, so it was already utilized in this patch.

generate_aescrypt_decryptBlock

I missed this case in initial multiversioning commit, so I multiversioned the decrypt intrisic also, thanks for pointing it out!

luhenry · 2024-09-19T08:30:26Z

@RealFYang following up on your questions. I would love to see this one go through as it promises some pretty significant gains on compatible hardware! Thanks again

RealFYang · 2024-09-19T08:34:05Z

@RealFYang following up on your questions. I would love to see this one go through as it promises some pretty significant gains on compatible hardware! Thanks again

Yeah, will take another look. Have you tried this on real hardware? Interesting to see the numbers.

luhenry · 2024-09-20T09:12:52Z

Yeah, will take another look. Have you tried this on real hardware? Interesting to see the numbers.

There is no real hardware that I know of that have vector crypto just yet. I expect it's one of these that we'll want to test as soon as hardware is available, and even possibly enable by default then

RealFYang · 2024-09-25T14:29:48Z

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp

+ for (int i = 0; i < reg_number; i++) {
+ __ vxor_vv(res, res, working_vregs[i]);
+ __ vaesdm_vv(res, vzero);
+ }


Seems that a lot more vxor.vv are emitted here compared with the openssl version [1]. I wonder if this could be further optimized. Or is there anything I missed? Thanks.

[1] https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aes-riscv64-zvkned.pl#L279-L295

You're absolutely right, thanks! Turned out I missed the fact that we can just use the encryption keys in reversed order for decryption

yhzhu20 · 2024-09-26T05:39:11Z

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp

+ const VectorRegister &vtemp, VectorRegister *working_vregs, int reg_number) {
+ assert(reg_number <= 14, "reg_number should be less than or equal to working_vregs size");
+
+ for (int i = 0; i < reg_number; i++) {


Hello, I have a question about the order of register handling in loops. Why is it in ascending order instead of descending? Here’s an example: https://github.com/riscv/riscv-crypto/blob/main/doc/vector/code-samples/zvkned.s.
And I look forward to your reply. Thanks.

Hi! It was in ascending order because I used different keys for encryption and decryption, while it is possible to use same set for both cases. Though both decryption implementations are functionally correct, the current one is more optimal

ArsenyBochkarev · 2024-10-17T22:21:59Z

Hi all! I'm sorry for such a late replies. I was able to optimize decryption sequence by using keys from encryption stage with reversed rounds order

8334999: RISC-V: implement AES single block encryption/decryption int…

02dc4e2

…rinsics

openjdk bot added the rfr Pull request is ready for review label Jun 30, 2024

openjdk bot added the hotspot [email protected] label Jun 30, 2024

robehn approved these changes Jul 1, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jul 1, 2024

luhenry reviewed Jul 1, 2024

View reviewed changes