Disallowing the dynamic loading of agents by default

[John Rose]

On Apr 3, 2017, at 3:36 PM, mark.reinhold at oracle.com wrote:
> 
> If developers and deployers have to to opt-in to breaking encapsulation
> on the command line then that at least makes it clear to someone trying
> to diagnose a failing system that something fishy might be going on.

It seems to me that some of the legitimate use cases use injected
code to perform similar diagnoses.  Having been many times on the
wrong side of a failing system, I am sympathetic with any diagnostic
tool, no matter how invasive.  And, yes, I give extra credit to tools
that can be applied online with no prearrangement.

This seems to lead back to allowing ad hoc code injection out
of the box.  Would it help if, although there was not an opt-in
on the command line, there was some restriction about the
nature of the injected code?  I'm thinking what we did with
JVMCI:  Opened up a deep hole into the JVM, and then
protected it by sealing it into a module.  Can we get the
module system to help us out here also?  Maybe, out of
the box, your code must be inside some particular module
in order to do monkey-patching.  Is there a way to do post
facto loading, during an emergency, into the privileged
module, of diagnostic code?  (Probably not; modules are
static.)

Anyway, I imagine there are ways for instrumentation code
to be loaded that are far more controlled and explicit than the
current state of affairs, and still won't require prearrangement.

Possibly all such ways will end up being too abusable.
But surely it is better to have a library that says "Hey,
I'm using/defining the monkey patching module", than
a random JAR that sneaks in and fires up a self-attach.

A couple of other thoughts:

1. The "execute from JAR" use case seems to want a hook
for command line options.  It's very ugly, but maybe that would
relieve pressure on users who cannot access command lines.
(But I'd much rather see problems solved by injecting a module
info file into a JAR, rather than some new command-line knobs.)

2. I think it is inevitable that we will be using the static structure
of modules, in future releases, to guide global optimizations.
Some of the hot-patching techniques people rely on today
will come into conflict with those optimizations.  The JVM is
amazing at dealing with dynamically changing configurations,
but we also need to keep the option for static optimizations open,
in the long term.  Sometimes the cost of switching from optimized
code to debug-mode must be so great that it won't be a viable
option, especially for online problem solving.

HTH
— John