Disallowing the dynamic loading of agents by default (revised)

[Andrew Dinn]

On 05/04/17 17:15, mark.reinhold at oracle.com wrote:
> Thanks to everyone for the quick feedback on this topic, and especially
> to Andrew for the constructive dialogue.
> 
> Here's a revised proposal:
> 
>   - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's
>     on by default in JDK 9 but off by default in JDK 10.
> 
>     This will allow launch scripts that use this option on JDK 10 to
>     work on JDK 9 without change, and will allow early testing of the
>     JDK 10 behavior on JDK 9.

This at the least is very welcome. It will give Red Hat and others the
time needed to prepare their users for for this change.

>   - Revise the `com.sun.tools.attach` API to forbid attachment to the
>     current process or to an ancestor of the current process, and
>     define a read-only system property that allows such attachment to
>     be enabled via the command line.
> 
>     This will discourage the inadvertent use of libraries that, for
>     better or for worse, intentionally violate strong encapsulation.

I guess I'm agnostic to this. I'm certainly not against it.

Is this change being proposed for JDK9 or JDK10? I'd prefer the latter
as that would give me more time to educate those using the Byteman
BMUnit package about the need to configure the requisite system
property. However, it's less of an issue than the
-XX:+EnableDynamicAgentLoading flag since, once configured, the system
property does no harm when switching from JDK9 back to JDK8.

>   - Enhance the `-jar` launcher option so that if the JAR file being
>     launched contains a `Premain-Class` attribute then it's launched
>     as both an application and as an agent for that application.
> 
>     This will allow `java -jar foo.jar` to be used in place of the
>     more verbose `java -javaagent:foo.jar -jar foo.jar` [1].

I have no comments to offer on this as it is not a scenario I have had
to deal with.

> Taken together, these changes are intended to enable the continued use
> of legitimate dynamically-loaded agents without change on JDK 9 and with
> a small change on JDK 10.  That later change will align the treatment of
> such agents with the other means of breaking encapsulation (`--add-opens`,
> etc.) in order to ensure integrity by default for all code.

That's a compromise position I can live with. Much as I want to retain
the ability to load my agent dynamically I also acknowledge that this is
one side of a trade-off. In particular, this proposal incorporates the
need for the JVM /eventually/ to have -- as a default -- a guarantee
that some portion of the code base cannot be subject to change and hence
is available for optimization without the need for ever more complex
apparatus to ensure later de-optimization. That's something I understand
the significance of and regard as very important for the future of the
JVM and JVM-based languages (not just Java).

This probably means that at some point (maybe JDK10 time, maybe later,
depending upon when this might start to deliver performance
improvements) Red Hat will decide to advise most of their Java customers
to run without the option to load dynamic agents. That may lose our
support team some opportunities to diagnose certain types of problems
but may also enable those customers to gain from performance improvements.

> This proposal does not attempt to lock down platform classes as distinct
> from user classes.  Many agents have legitimate reasons to transform
> platform classes, so an additional mechanism to protect those classes
> does not appear to be worthwhile.

I'm happy with this although it might be worth reviewing it later.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander