Disallowing the dynamic loading of agents by default

[mark.reinhold at oracle.com]

2017/4/4 3:45:02 -0700, Andrew Dinn <adinn at redhat.com>:
> Thanks again for another thoughtful and well-reasoned response.

Thank you for the continued dialogue.

> On 03/04/17 23:36, mark.reinhold at oracle.com wrote:
>> 2017/4/3 9:44:43 -0700, Andrew Dinn <adinn at redhat.com>:
>>> ...
>>> 
>>> I'm very happy to consider all sorts of half-way houses or even -- in
>>> time -- the full change recommended in the original JIRA. For example,
>>> rejecting instrumentation in some specific set of bootstrap/JDK module
>>> classes (like, say, java.base) from an agent which has been dynamically
>>> loaded might well be a workable compromise -- that at least allows users
>>> to employ an agent to tweak any code that is in the classpath through
>>> their choice.
>> 
>> That's an interesting option, and worth exploring further.  It could,
>> though, be troublesome for legitimate late-binding agents that instrument
>> JDK internals.  Is Byteman typically used in that way?
> 
> Well, if it helps to provide the guarantees that the JDK runtime or core
> runtime wants in order to enable performance improvements then I'd
> certainly be /interested/ in a restriction that merely put certain
> classes out of reach of dynamic agents (assuming it also comes with an
> option to remove that restriction).
> 
> Of course,-- to answer your question -- that would still present a
> problem for Byteman; it is often used to inject into core (java.base)
> classes.
> 
>   There are quite a few unit/integration testing scenarios where the
> ability to tweak the operation of core JDK runtime code is really
> useful. For example, injecting a THROW rule into class File to simulate
> an IOException is probably the poster-child for Byteman fault injection.
> 
>   The same also applies when using Byteman for runtime diagnosis. A very
> good example of that was when one of our customers kept finding that the
> first connection obtained from a connection pool would always fail with
> a connection error. Trace code injected into Thread.isInterrupted
> revealed the reason for the failure -- the application thread's
> interrupt state was already set before the open attempt. A stack
> backtrace call injected into Thread.setInterrupted showed that a 3rd
> party library was invalidly setting (and then not clearing) the
> interrupted state as part of application thread initialization.

Very interesting use cases!

> So, in summary:
> 
> I'm interested in the option for a default setting to provide limited
> access to runtime and/or application classes from dynamically loaded
> agents -- it's an improvement on no access at all.

Got it.

> However, on Byteman's account, I'd still really prefer the ability to
> support full access in the JDK9 time frame with a move to whatever more
> limited access is determined appropriate in JDK10 (for the reasons
> already mentioned).

Okay, I think I'm starting to see how to revise the proposal.
I'll try to write something up and post it tomorrow.

- Mark