Disallowing the dynamic loading of agents by default

[Christoph Engelbert]

Comments inlined

Chris

> On 5. Apr 2017, at 07:19, John Rose <john.r.rose at oracle.com> wrote:
> 
> 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.

Not the only tools, as we have this “uber-jar” use case but I think that might have a better solution than the more general one we’re looking for to support those diagnostic tools :)

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

I already proposed, more as a side note, something like the Ubuntu / Debian alike repository private-public key signatures. If I want to have “privileged” modules (for example agents being attached at runtime) I have to trust the signature key. Anyhow I’m not looking for a certification process from Oracle side but a user can trust / mistrust key-pairs on their own by something like “jtrust add https://repository.company.com/key.asc <https://repository.company.com/key.asc>” which would be easy to explain to customers, adds a general “trust process” to all modules (for example to be reused in SecurityManager) and maybe other use cases.

Still just a fix idea but maybe something to look into in the long term.

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

It could be solved with layers (or different class loaders) and only modules on the same layer as the main JAR are ok to directly attach (in this specific use case)?

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