Disallowing the dynamic loading of agents by default (revised)

[mark.reinhold at oracle.com]

2017/4/6 3:09:49 -0700, Andrew Dinn <adinn at redhat.com>:
> 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?

JDK 9.  With `-XX:+EnableDynamicAgentLoading` off by default in JDK 9,
this is one of the few ways we have left to discourage the use of
encapsulation-busting libraries.

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

Indeed!  That's a good summary of the tradeoff.

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

Yes -- it wouldn't surprise me if we come back to this as we start to
leverage integrity invariants for optimization.

- Mark