Skip to content

8343984: Fix Unsafe address overflow #22027

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

Closed

Conversation

wenshao
Copy link
Contributor

@wenshao wenshao commented Nov 12, 2024

In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.


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

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 22027

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

Using diff file

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

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Nov 12, 2024

👋 Welcome back swen! 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
Copy link

openjdk bot commented Nov 12, 2024

@wenshao This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8343984: Fix Unsafe address overflow

Reviewed-by: pminborg, alanb

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 21 new commits pushed to the master branch:

  • c78de7b: 8343964: RISC-V: Improve PrintOptoAssembly output for loadNKlassCompactHeaders node
  • eb40a88: 8343430: RISC-V: C2: Remove old trampoline call
  • b26e495: 8343801: Change string printed by nsk_null_string for null strings
  • a4e2c20: 8343344: Windows attach logic failed to handle a failed open on a pipe
  • 63eb485: 8343883: Cannot resolve user specified toolchain-path for lld after JDK-8338304
  • db85090: 8338411: Implement JEP 486: Permanently Disable the Security Manager
  • c12b386: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash ciMethodData
  • 81752c4: 8338565: Test crashed: assert(is_path_empty()) failed: invariant
  • e5eaa7f: 8343946: JFR: Wildcard should only work with COUNT for 'jfr view'
  • 2989d87: 8343805: RISC-V: JVM crashes on startup when disabling compressed instructions
  • ... and 11 more: https://git.openjdk.org/jdk/compare/cbf4dd588bf371e13e81204b1585d34bfadddb42...master

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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk
Copy link

openjdk bot commented Nov 12, 2024

@wenshao The following labels will be automatically applied to this pull request:

  • core-libs
  • nio
  • serviceability

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

@openjdk openjdk bot added serviceability serviceability-dev@openjdk.org nio nio-dev@openjdk.org core-libs core-libs-dev@openjdk.org labels Nov 12, 2024
@wenshao
Copy link
Contributor Author

wenshao commented Nov 12, 2024

There are two other possible address overflow issues that are difficult to fix:

java.util.zip.CRC32C::updateBytes
jdk.internal.util.ArraysSupport::mismatch

@wenshao wenshao changed the title Fix Unsafe address overflow 8343984: Fix Unsafe address overflow Nov 12, 2024
@openjdk openjdk bot added the rfr Pull request is ready for review label Nov 12, 2024
@mlbridge
Copy link

mlbridge bot commented Nov 12, 2024

@minborg
Copy link
Contributor

minborg commented Nov 12, 2024

It would be good to add some tests to ensure long precision is used.

@minborg
Copy link
Contributor

minborg commented Nov 12, 2024

The generation of Java files works a bit differently from other places in the JDK (e.g. NIO). Now that the template has been changed, you also need to manually run the script gen-src.sh in order to regenerate the classes. So, they will then show up like they did in an earlier commit but share a single source of truth.

Copy link
Contributor

@minborg minborg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. If there are no additional tests, please label the JBS issue appropriately (i.e noreg-*)

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Nov 12, 2024
@wenshao
Copy link
Contributor Author

wenshao commented Nov 12, 2024

I want to add such a test case, but I am worried that it will consume too many resources during the build process.

/**
 * @test
 * @bug 8343984
 * @summary Test that the append capacity is close to Integer.MaxValue
 * @run main/othervm -Xms6g -Xmx6g HugeAppend
 */

public final class HugeAppend {
    public static void main(String[] args) {
        StringBuilder buf = new StringBuilder();
        int loop4 = Integer.MAX_VALUE / 4;
        for (int i = 0; i < loop4; i++) {
            buf.append(true);
        }

        buf.setLength(0);
        int loop5 = Integer.MAX_VALUE / 5;
        for (int i = 0; i < loop5; i++) {
            buf.append(false);
        }
    }
}

@minborg
Copy link
Contributor

minborg commented Nov 12, 2024

I want to add such a test case, but I am worried that it will consume too many resources during the build process.

/**
 * @test
 * @bug 8343984
 * @summary Test that the append capacity is close to Integer.MaxValue
 * @run main/othervm -Xms6g -Xmx6g HugeAppend
 */

public final class HugeAppend {
    public static void main(String[] args) {
        StringBuilder buf = new StringBuilder();
        int loop4 = Integer.MAX_VALUE / 4;
        for (int i = 0; i < loop4; i++) {
            buf.append(true);
        }

        buf.setLength(0);
        int loop5 = Integer.MAX_VALUE / 5;
        for (int i = 0; i < loop5; i++) {
            buf.append(false);
        }
    }
}

Yeah. I think it is reasonable to leave out such tests.

@wenshao
Copy link
Contributor Author

wenshao commented Nov 12, 2024

macos-aarch64 build error, I have been encountering this problem for the past two days. How do I solve it?

Run # On macOS we need to install some dependencies for testing
  # On macOS we need to install some dependencies for testing
  brew install make
  sudo xcode-select --switch /Applications/Xcode_14.3.1.app/Contents/Developer
  # This will make GNU make available as 'make' and not only as 'gmake'
  echo '/usr/local/opt/make/libexec/gnubin' >> $GITHUB_PATH
  shell: /bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    MSYS[2](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:2)_PATH_TYPE: minimal
    CHERE_INVOKING: 1
==> Downloading https://ghcr.io/v2/homebrew/core/make/manifests/4.4.1-1
==> Fetching make
==> Downloading https://ghcr.io/v2/homebrew/core/make/blobs/sha256:94[3](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:3)77dc5a364da305c75fd7aa923a[4](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:4)2897993de9edd1eb074428e13c3f2aaf93
==> Pouring make--4.4.1.arm64_sonoma.bottle.1.tar.gz
==> Caveats
GNU "make" has been installed as "gmake".
If you need to use it as "make", you can add a "gnubin" directory
to your PATH from your bashrc like:

    PATH="/opt/homebrew/opt/make/libexec/gnubin:$PATH"
==> Summary
🍺  /opt/homebrew/Cellar/make/4.4.1: 1[7](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:7) files, 1.3MB
xcode-select: error: invalid developer directory '/Applications/Xcode_14.3.1.app/Contents/Developer'
Error: Process completed with exit code 1.

@wenshao
Copy link
Contributor Author

wenshao commented Nov 12, 2024

I made a mistake, I ran the wrong jtreg, edited it, please ignore it

@openjdk openjdk bot removed the ready Pull request is ready to be integrated label Nov 12, 2024
@wenshao
Copy link
Contributor Author

wenshao commented Nov 12, 2024

@AlanBateman @minborg
Sorry, after you approved it, I found that there are still offset overflows in ZipUtils and UnixUserDefinedFileAttributeView, so I submitted the changes again. Please help review it again.

@AlanBateman
Copy link
Contributor

@AlanBateman @minborg Sorry, after you approved it, I found that there are still offset overflows in ZipUtils and UnixUserDefinedFileAttributeView, so I submitted the changes again. Please help review it again.

Looks good, can you bump the copyright header on UnixUserDefinedFileAttributeView too?

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Nov 12, 2024
@openjdk openjdk bot removed the ready Pull request is ready to be integrated label Nov 12, 2024
@wenshao
Copy link
Contributor Author

wenshao commented Nov 12, 2024

@liach provided a new idea, which is to change the type of jdk.internal.misc.Unsafe.ARRAY_XXX_OFFSET from int to long. I think @liach's idea is better, that is the way to completely solve this problem.

@AlanBateman
Copy link
Contributor

@liach provided a new idea, which is to change the type of jdk.internal.misc.Unsafe.ARRAY_XXX_OFFSET from int to long. I think @liach's idea is better, that is the way to completely solve this problem.

I discussed this briefly with him today, he's looking into the implications of doing that.

@liach
Copy link
Member

liach commented Nov 12, 2024

I think this patch can go ahead: the change to internal unsafe will affect many other components and all use sites will get bytecode updates. The more comprehensive change will need more throughout investigation and testing, while the fixes here are straightforward and easy to verify.

Co-authored-by: Andrey Turbanov <turbanoff@gmail.com>
@openjdk openjdk bot added the ready Pull request is ready to be integrated label Nov 13, 2024
Copy link
Contributor

@minborg minborg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great with the additional fixes.

@wenshao
Copy link
Contributor Author

wenshao commented Nov 13, 2024

/integrate

@openjdk
Copy link

openjdk bot commented Nov 13, 2024

Going to push as commit 0dab920.
Since your change was applied there have been 45 commits pushed to the master branch:

  • 168b18e: 8343958: Remove security manager impl in java.lang.Process and java.lang.Runtime.exec
  • 5ac330b: 8344039: Remove security manager dependency in java.time
  • 1eb38c8: 8343219: Manual clientlibs test failures after SM removal
  • dde6230: 8343416: CDS dump fails when unregistered class can also be loaded from system modules
  • ffea980: 8344023: Unnecessary Hashtable usage in LdapClient.defaultBinaryAttrs
  • 5e01c40: 8343981: Remove usage of security manager from Thread and related classes
  • dbf2346: 8341260: Add Float16 to jdk.incubator.vector
  • a5f11b5: 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability)
  • 7be7772: 8344112: Remove code to support security manager execution mode from DatagramChannel implementation
  • bd3fec3: 8344086: Remove security manager dependency in FFM
  • ... and 35 more: https://git.openjdk.org/jdk/compare/cbf4dd588bf371e13e81204b1585d34bfadddb42...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Nov 13, 2024
@openjdk openjdk bot closed this Nov 13, 2024
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Nov 13, 2024
@openjdk
Copy link

openjdk bot commented Nov 13, 2024

@wenshao Pushed as commit 0dab920.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org integrated Pull request has been integrated nio nio-dev@openjdk.org serviceability serviceability-dev@openjdk.org
Development

Successfully merging this pull request may close these issues.

5 participants