Disallowing the dynamic loading of agents by default

[Mario Torre]

Hi Mark,

I understand the need for consistency and I agree with your rationale.

I think though that a solution that requires a command line switch for such
cases is too restrictive.

The problem is that the main users of this API are generally agents that
are injected after a particular problem may arise. Requiring a command line
switch like this means that for those use cases you must restart the
applications, or effectively always turn on the feature, which practically
invalidates the need for this restriction.

I wonder if the JDK should not instead have a default serviceability agent
that can have a runtime impact on this flag, something more restricted than
a generic JMX agent.

I already see support engineers starting to recommend go to customers :)

Seriously though, it seems to me that this restriction should be better
thought and perhaps left for later (I understand that this means people
will need to change their command lines twice,but this solution seems very
rushed).

Cheers,
Mario

On Thu 30. Mar 2017 at 17:39, <mark.reinhold at oracle.com> wrote:

> // 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.
>