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 java.lang. 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.reinh...@oracle.com>: > 2017/4/2 23:28:02 -0700, ch...@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
