// Moving the general discussion to jigsaw-dev for the record;
// bcc'ing {hotspot-runtime,serviceability}-dev for reference.Andrew, Thanks for your feedback on this topic [1][2][3]. First, we apologize for the way in which this topic was raised. Our intent was to post a proposal for discussion prior to code review, but unfortunately that review was posted prematurely (as is evident by its inclusion of Oracle-internal e-mail addresses and URLs). Second, I agree with your earlier analysis as to the security impact of this change. If an attack is possible via this vector then closing the vector would only slow the attack, not prevent it. The motivation for this change is, however, not merely to improve the security of the platform but to improve its integrity, which is one of the principal goals of the entire modularity effort. Integrity has benefits for security and also for maintainability, of both the JDK itself and of code that runs upon it, since it makes it clear exactly which APIs are intended for external use, and which are not. To improve platform integrity we've strongly encapsulated (most) of the internal APIs of the JDK. That can be, as we all know, a source of pain for developers trying to get existing applications to run on JDK 9, so we've provided workarounds via the encapsulation-busting `--add-opens` and `--add-exports` command-line options and, recently, the temporary but more powerful (and verbose) `--permit-illegal-access` option. There are no API equivalents to these command-line options [4]. That's intentional: We want developers and deployers using Java out-of-the-box to be assured that their code is only using APIs actually intended for external use. They can choose explicitly to expose internal APIs, via the command line, but then that's a deliberate choice that they make, and they own the consequences. It's reasonable to allow this via the command line since we assume that anyone with access to the command line already has the power to corrupt the JDK in any way they please. The proposal to disable the loading of dynamic agents by default is one more part of the overall integrity story. As things stand today, code in any JAR file can use the `VirtualMachine.loadAgent` API to load an agent into the JVM in which it's running and, via that agent, break into any module it likes. Changing the default and providing a new command-line option, in this case `-XX:+EnableDyanmicAgentLoading`, is consistent with the other encapsulation-busting options we've introduced. It allows a developer or deployer to choose to bend, if not violate, the integrity of the platform, yet also to know that by default the platform is whole. (Changing this default is also consistent, as Alan has noted, with the original intent of the `VirtualMachine.loadAgent` API.) I understand your points about the practical difficulties of having to educate users about this new option and enhance startup scripts to use the option only when invoking JDK 9. Isn't it already the case, however, that migrating existing applications to JDK 9 is often going to require the use of a few new options anyway, in order to expose internal APIs? If so then would it really be that much more burdensome for users also to think explicitly, at the same time, about whether they want to enable dynamic agent loading? This change would be disruptive to some but it's the best way we've found, so far, to preserve platform integrity in the face of dynamic agent loading. If there's a better way to do that, we'd like to know. - Mark [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-March/022948.html [2] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-March/022951.html [3] https://bugs.openjdk.java.net/browse/JDK-8177154 [4] There are limited reflective APIs via which code in a module can apply some of these operations to just that module, and via which code that creates a module layer can do so for modules in that layer, but none of these APIs can break into arbitrary modules.
