JDK 17: `--illegal-access=permit` removed

There are some known issues with Ghidra and JDK 17, which is scheduled to be released on 09/14/2021.

This issue is to address the OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit; support was removed in 17.0 warning you get when launching Ghidra with JDK 17.

The following table outlines how each illegal access can occur within Ghidra. The bold entries are relevant to the Ghidra client application:

Source	Target	Scenario
net.sf.cglib.core	java.base/java.lang	Importing new binary into Ghidra (Raw Binary becomes only choice)
org.apache.felix.framework	java.base/java.net	Closing CodeBrowser
com.google.gson.internal	java.base/java.util	https://github.com/google/gson/issues/1875
ghidra.framework.GhidraApplicationConfiguration	java.desktop/sun.awt.X11	Setting application title on Linux
ghidra.docking.util.painting.GRepaintManager	java.desktop/sun.awt.image	Running in “Inverted Colors” mode
ghidra.net.ApplicationKeyManagerUtils	java.base/sun.security.x509	Connecting to shared project using PKI
ghidra.net.ApplicationKeyManagerUtils	java.base/sun.security.util	Connecting to shared project using PKI
ghidra.server.RepositoryManager	java.rmi/sun.rmi.transport.tcp	Server RMI
ghidra.net.ApplicationKeyManagerUtils	java.base/sun.security.provider	Server tests
ghidra.util.task.CachingSwingWorkerTest	java.desktop/sun.swing	Swing tests
ghidra.app.util.headless.MyHeadlessGraphicsEnvironment	java.desktop/sun.java2d	Headless tests

Solution: Add the following JVM arguments to launch.properties and Ghidra.launch:

VMARGS=--add-opens java.base/java.lang=ALL-UNNAMED
VMARGS=--add-opens java.base/java.util=ALL-UNNAMED
VMARGS=--add-opens java.base/java.net=ALL-UNNAMED
VMARGS=--add-opens java.desktop/sun.awt.image=ALL-UNNAMED
VMARGS=--add-opens java.base/sun.security.x509=ALL-UNNAMED
VMARGS=--add-opens java.base/sun.security.util=ALL-UNNAMED
VMARGS_LINUX=--add-opens java.desktop/sun.awt.X11=ALL-UNNAMED

An equivalent solution will have to be implemented for tests and the server, which do not currently use launch.properties. That will be handled in a different ticket.

If this is not fixed, several jars that perform illegal reflective accesses will not function properly, as we saw with JDK 16 in #2879, #2888, #2904, #2999, and #3030.

Issue Analytics

State:
Created 2 years ago
Reactions:4
Comments:11 (2 by maintainers)

Top GitHub Comments

2reactions

homes410commented, Aug 24, 2021

Below are lines that appended to launch.properties for ghidra 9.2.4 working in windows 10 - eclipse-temurin-java17-beta.

VMARGS=–add-opens=java.base/java.util=ALL-UNNAMED VMARGS=–add-opens=java.base/java.lang=ALL-UNNAMED VMARGS=–add-opens=java.base/java.net=ALL-UNNAMED VMARGS=–add-opens=java.base/sun.nio.ch=ALL-UNNAMED VMARGS=–add-opens=java.desktop/java.awt.event=ALL-UNNAMED VMARGS=–add-opens=java.desktop/sun.awt.image=ALL-UNNAMED VMARGS=–add-opens=java.desktop/java.awt=ALL-UNNAMED VMARGS=–add-opens=java.desktop/sun.awt=ALL-UNNAMED VMARGS=–add-opens=java.desktop/sun.swing=ALL-UNNAMED VMARGS=–add-opens=java.desktop/javax.swing=ALL-UNNAMED VMARGS=–add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED VMARGS=–add-opens=java.desktop/javax.swing.plaf.basic=ALL-UNNAMED VMARGS=–add-opens=java.desktop/sun.java2d=ALL-UNNAMED VMARGS=–add-opens=java.desktop/sun.awt.windows=ALL-UNNAMED VMARGS=–add-opens=java.desktop/sun.font=ALL-UNNAMED VMARGS=–add-opens=java.base/sun.net.www.protocol.file=ALL-UNNAMED VMARGS=–add-opens=java.base/sun.net.www.protocol.ftp=ALL-UNNAMED VMARGS=–add-opens=java.base/sun.net.www.protocol.http=ALL-UNNAMED VMARGS=–add-opens=java.base/sun.net.www.protocol.https=ALL-UNNAMED VMARGS=–add-opens=java.base/sun.net.www.protocol.jar=ALL-UNNAMED VMARGS=–add-opens=java.base/sun.net.www.protocol.jmod=ALL-UNNAMED VMARGS=–add-opens=java.base/sun.net.www.protocol.mailto=ALL-UNNAMED VMARGS=–add-opens=java.base/sun.net.www.protocol.jrt=ALL-UNNAMED VMARGS=–add-opens=java.base/jdk.internal.loader=ALL-UNNAMED VMARGS=–add-opens=java.base/java.security=ALL-UNNAMED

1reaction

xiaoyinlcommented, Aug 31, 2021

@ryanmkurtz I saw there’s a related issue in gson: https://github.com/google/gson/issues/1875. The workaround is to add --add-opens java.base/java.util=ALL-UNNAMED. Since some extensions use gson, do we need to add this argument to launch.properties too?

Top Results From Across the Web

Internal JDK Elements Strongly Encapsulated in JDK 17 - InfoQ

The new default --illegal-access=permit opens all internal code to unnamed modules in which code may access the internal APIs via reflection. An ...

A peek into Java 17: Encapsulating the Java runtime internals

In Java 16, it is still possible to restore the situation that existed previously by using the --illegal-access command-line switch to allow ...

Now if you want to really abuse Java, try this one - Hacker News

Support for --illegal-access=permit was removed with Java 17. But you can use "--add-opens=java.base/java.lang=ALL-UNNAMED" instead if you really want.

In Java 17 how do I avoid resorting to --add-opens?

We expect to remove the --illegal-access option entirely in a future release. Because of this, using openjdk17 early access builds, I'm seeing ...

Java 9 Illegal Reflective Access Warning - Baeldung

From Java 9, the –illegal-access=permit is the default mode. ... Since Java 17, the –illegal-access option is entirely removed.