8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512)

[martinuy]

Hi all,

This pull request contains a backport of commit 8a8d9288 from the openjdk/jdk repository.

The commit being backported was authored by Martin Balao and Francisco Ferrari on 24 Apr 2024 and was reviewed by Andrew Haley and Sandhya Viswanathan. JDK-21 is affected by the bug JDK-8330611 as it was introduced by JDK-8233741 in JDK 14.

Thanks!

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8330611 needs maintainer approval

Issue

• JDK-8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) (Bug - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk21u-dev.git pull/531/head:pull/531
$ git checkout pull/531

Update a local copy of the PR:
$ git checkout pull/531
$ git pull https://git.openjdk.org/jdk21u-dev.git pull/531/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 531

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk21u-dev/pull/531.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mbalao! 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]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[openjdk]

⚠️ @martinuy This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[mlbridge]

Webrevs

• 00: Full (2bb314c2)

[martinuy]

/approval request Please consider this bug fix for jdk21u, as this release is affected. The JDK main line patch applies cleanly. The scope of the change is limited to the AES-CTR intrinsic for x86_64 AVX-512. I ran all the same testing as for JDK main line, no regressions were observed in hotspot/jtreg/compiler/codegen/aes and I manually verified that the bug was fixed.

[openjdk]

@martinuy
8330611: The approval request has been created successfully.

[GoeLin]

HI @martinuy, please do the 22 backport first. Also, to me, this seems a quite risky fix to backport right after pushing to head. Could we wait for the October release?

[martinuy]

HI @martinuy, please do the 22 backport first. Also, to me, this seems a quite risky fix to backport right after pushing to head. Could we wait for the October release?

With the review done for the main line patch and the testing done for both main line and jdk21u, I think that the risk has been reasonably addressed. There is time until the next release for further testing if it goes in now. The other side of the story is that if the bug conditions are met, a jdk21u JVM will crash with a segmentation fault. While there is a workaround (-XX:-UseAESCTRIntrinsics), the bug does not happen consistently enough and is hard to troubleshoot. @charlesconnell you may want to give some input on how this bug affects you.

[charlesconnell]

Thanks @martinuy. At Hubspot we store most of our data in HBase. We continually replicate HBase's write-ahead-log to S3 as a backup mechanism. We also do full backups daily or weekly. All of this requires pulling all the data out of HBase/Hadoop over Kerberos connections, which we configure to use encryption with cipher suite AES/CTR/NoPadding. We see dozens of this crash per day in our write-ahead-log persister tool, although that is mostly harmless to us. More impactfully, we have been forced to run the full backups on aarch64 machines, because they could not complete successfully on x86_84 machines, because of this bug. In other words, given enough AES traffic, this bug is not rare.

I suspect that there are not many other organizations with this same combination of circumstances (lots of data in Hadoop, accessed frequently with Kerberos + AES/CTR/NoPadding), but if there are, I imagine they are experiencing the same problems.

[GoeLin]

Hi @Marinuy, this seems a very unlikely bug, so I think we should defer this to the October release and give it some time to proove in 22.

[bridgekeeper]

@martinuy 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!