New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8280703: CipherCore.doFinal(...) causes potentially massive byte[] allocations during decryption #1780
Conversation
👋 Welcome back sgibbons! A progress list of the required criteria for merging this PR into |
This backport pull request has now been updated with issue from the original commit. |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
can you please run GHA |
@asgibbons This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 16 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@RealCLanger) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
Noob here - what is GHA? |
GHA= GitHub Actions. You have to enable it in your repository fork. Then you will also be able to trigger the run for your PR branch. |
Thanks @RealCLanger. I triggered a run and will integrate when complete. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm after your merges the resulting change looks incorrect.
@RealCLanger - Sorry for the churn. I had a slight mixup in the myriad of JDK trees I'm concurrently maintaining. I fixed the issue and manual testing along with tier1 testing have successfully completed. Please review and approve if this is acceptable. |
@ascarpino Could you please help review this backport CR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a closer look now. Overall it seems ok. Could you maybe rename outWithPadding to internalOutput? That would bring the code closer to head and seems the more logical name for the buffer. Thanks.
System.arraycopy(outWithPadding, 0, output, outputOffset, outLen); | ||
// decrypt mode. Zero out output data that's not required | ||
Arrays.fill(outWithPadding, (byte) 0x00); | ||
if(outWithPadding != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a space after if
@@ -968,9 +974,9 @@ private void endDoFinal() { | |||
} | |||
} | |||
|
|||
private int unpad(int outLen, byte[] outWithPadding) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here the variable should remain outWithPadding.
throws BadPaddingException { | ||
int padStart = padding.unpad(outWithPadding, 0, outLen); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
Thanks. This looks good. I'll run it through SAP'S nightlies and will hopefully approve tomorrow when no regressions spotted. |
Thank you very much @RealCLanger ! |
The backport looks consistent with what was put in recent releases. |
Something that should be verified is that this doesn't expose failed auth tag decrypted GCM data or other GCM decryption. There maybe some unexpected differences as this change was after GCM separated from CipherCore in 17. I believe GCM still uses CipherCore in 11. |
Thanks, @ascarpino. Are there any tests I can run to verify that no GCM data have been exposed? It appears to me that there's one place where decrypted data could be leaked (ShortBufferException), but this is the same in newer versions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good from my perspective now. SAP tests passed. Can't say anything to the GCM topic brought up by @ascarpino, though.
@ascarpino I have been looking to see whether any data could be potentially leaked as a result of my change and cannot envision such a scenario. It appears to me that my change is functionally identical to what it would be without the change. Can you please provide more details? Thanks. |
I believe there is no additional risk to data leakage as the result of this change, so I'm proposing integration. Thanks. /integrate |
@asgibbons |
ok /sponsor |
Going to push as commit 479ddb6.
Your commit was automatically rebased without conflicts. |
@RealCLanger @asgibbons Pushed as commit 479ddb6. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Backporting because this change results in ~3x performance improvement in AES-CTR.
Risk is low. Tested with tier1 and benchmark.
The PR does not backport cleanly. The buffer name was changed, but functionally remains the same.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk11u-dev pull/1780/head:pull/1780
$ git checkout pull/1780
Update a local copy of the PR:
$ git checkout pull/1780
$ git pull https://git.openjdk.org/jdk11u-dev pull/1780/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1780
View PR using the GUI difftool:
$ git pr show -t 1780
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk11u-dev/pull/1780.diff