On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter <winterhal...@openjdk.org> wrote:
>> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed >> from `sun.misc.Unsafe`. > > Rafael Winterhalter has refreshed the contents of this pull request, and > previous commits have been removed. The incremental views will show > differences compared to the previous content of the PR. The pull request > contains one new commit since the last revision: > > 8200559: Java agents doing instrumentation need a means to define auxiliary > classes > This won't work as agents are loaded by the system class loader, not the boot > loader. Peter Levart ***@***.***> schrieb am Mo., 19. Apr. 2021, 11:02: > […](#) > From: Alan Bateman JDK-8200559 is about defining auxiliary classes in the > same runtime package at load-time whereas I think the proposal in this PR is > adding an unrestricted defineClass to the Instrumentation class. I think this > will require a lot of discussion as there are significant issues and concerns > here. An unrestricted defineClass might be okay for tool/java agents when > started from the command line with -javaagent but only if the Instrumentation > object is never ever leaked to library or application code. It could > potentially be part of a large effort to reduce the capabilities of agents > loaded via the attach mechanism. More generally I think we need clearer > separation of the requirements of tool agents from the requirement of > framework/libraries that want to inject proxy and other classes at runtime. I > think it would be easy to limit the use of this Instrumentation method to the > agent code as agent classes are loaded by the bootstrap classloader. Simply > make the method imp lementation caller-sensitive and check the caller is from bootstrap class loader. This way Instrumentation instance escaped to application code would not give that code any ability to define arbitrary classes. Good enough? Peter Separately, the proposal in JEP 410 is to terminally deprecate ProtectionDomain. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <[#3546 (comment)](https://github.com/openjdk/jdk/pull/3546#issuecomment-822302347)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCIA4EYHK5OHTDAN3FKYULTJPWS5ANCNFSM43BSDEGQ> . Ah sorry, I didn't know that. So what about the following: agent is able to define (or load) a class from bootstrap loader. So it would be able to instantiate an intermediary class, loaded by bootstrap loader which would serve as an intermediary to call into this limited Instrumentation API point... Or better: add a Lookup parameter to the Instrumentation method. The implementation would check that the Lookup is an unrestricted Lookup from a class loaded by bootstrap loader. Agent would just have to take the pain of obtaining such Lookup instance... ------------- PR: https://git.openjdk.java.net/jdk/pull/3546
