Disallowing the dynamic loading of agents by default

Hannes Kegel hannes.kegel at ej-technologies.com
Tue Apr 4 11:14:19 UTC 2017

Hi Mark, hi Alan, hi all,

I am one of the developers of JProfiler and would like to share our
thoughts and suggestions regarding this change.

My understanding is that the goal is to prevent libraries from using
agents to break access checks while not disrupting all other agent use
cases as far as possible. I understand that the integrity of the
module system is an important goal - on the other hand, our customers
really rely on being able to dynamically attach to any JVM for
troubleshooting, though.

1) Did you consider differentiating between native and java agents?
First, I don't think using native libraries for all platforms would be
a popular stackoverflow solution. Second, if a native library is in
play it would be easier to just use JNI or call JVM functions directly
to get what you want. So I think it would not harm the main goal to
handle native agents like in Java 6 to 8. That would keep the class of
full stack profilers available to Java users for troubleshooting.

2) Apart from that, restricting what a java agent can do in attach
mode looks like a good compromise to us. We need to retransform
java.base classes, though, and there are very interesting use cases
for java agents, too. Think for example of a troubleshooting tool that
monitors thread usage. It would most probably have to instrument

In the light of this argument, could you consider to narrow down the
number of classes that cannot be retransformed, please? As methods
cannot be added and access modifiers cannot be changed, I think
protecting the classes that perform access checks like
AccessibleObject and the respective method handle classes could be
enough. I think an annotation to keep track of these classes would be
great. Of course there are other ways to leak or modify internal data
if retransforming classes is allowed, but they would be very hacky and
I don't think library authors would be able to rely on them.

If method adding or access modification is enabled in a future Java
release, these type of modifications could be prevented for java.base.

3) If some retransformations would be allowed in java.base, you will
still of course want to prevent that open or export edges are added.
Read edges would be needed, though. redefineModule could throw an
UnsupportedOperationException if open or export edges are added
(similar to retransformClasses or the UNSUPPORTED_REDEFINITION error
codes for retransforming classes with the native API).

4) A command line switch that removes the new restrictions on dynamic
agents would be still needed, though.

Thanks for your consideration,

Hannes Kegel
ej-technologies GmbH

2017-04-04 1:19 GMT+02:00  <mark.reinhold at oracle.com>:
> 2017/4/2 23:28:02 -0700, chris at hazelcast.com:
>> First of all, I understand the idea behind this change and I think it
>> certainly makes sense but from my impression the default is wrong, as
>> Volker already pointed out.
>> Over the last few days I (with the help of others) put together a
>> document ...
> Thanks -- that's useful data.
>> Looking at APM, as Martijn, mentioned, I don’t see a lot of impact, as
>> most APMs should be added right from the start of the JVM. On the
>> other hand, however, it seems that there is a lot of tools (probably
>> more on the “devops” side of things), that are commonly added at
>> runtime in case of a problem or error. Those tools would be greatly
>> affected by the change and would require to commonly deactivate the
>> new restriction which renders it kind of useless.
> From your document it looks like it's mainly profilers that might need
> to transform core JDK classes.  Do you have any sense as to whether the
> other types of agents can still be effective if they cannot transform
> core classes, an option that Andrew suggested?
>> That said it looks like the main group being affected by this change
>> is not developers, as you seem to have mentioned in the initial mail,
>> but operations. Furthermore I’m not sure I agree with “if you have to
>> tell customers to put additional flags on CL, one more is no problem”
>> (as it sounded below). Normally you have to explain / fight over every
>> single command line parameter that has to be set with the customers
>> operations team (except those parameters are GC configs ;-). That
>> means it’ll be really hard to explain why to deactivate something that
>> undercuts the system security / integrity, as it will be put.
> That's a fair point.
>> Most interestingly, as the document points out, there will be ways to
>> undermine the change by creating a remote thread (on Windows) or
>> ptrace on Linux. There are certainly ways on each of the operating
>> systems but it’ll make things even more insecure.
> I think this is a red herring.  If you have the power to ptrace a Java
> process then you can likely already do anything, and there's not much we
> can do to stop you.
> - Mark

More information about the jigsaw-dev mailing list