Proposals for some open JPMS issues, #ReflectiveAccessByInstrumentationAgents

[Remi Forax]

----- Mail original -----
> De: "Andrew Dinn" <adinn at redhat.com>
> À: "mark reinhold" <mark.reinhold at oracle.com>, jigsaw-dev at openjdk.java.net, jpms-spec-comments at openjdk.java.net
> Envoyé: Lundi 4 Juillet 2016 14:26:34
> Objet: Re: Proposals for some open JPMS issues,	#ReflectiveAccessByInstrumentationAgents
> 
> On 28/06/16 22:47, mark.reinhold at oracle.com wrote:
> > FYI, I've just posted proposals for some of the open issues in the
> > draft JPMS specification, including:
> >   . . .
> >   #ReflectiveAccessByInstrumentationAgents
> >   . . .
> 
> I am not sure the proposed solution is going to work for my agent and it
> may well be a problem for other agents for a similar reason. At root,
> the problem is that the new API seems to be tackling a different problem
> to the one which motivated me to raise this issue.
> 
> The new API allows an agent to rewrite any arbitrary module M so that it
> exports a previously hidden package P to some other module M'.
> Exercising this API would indeed be sufficient to allow methods of
> classes in M' to obtain references to non-public methods/fields of
> classes in package P, enable access and then invoke/access them via
> reflection. It would also allow the enabled references to be selectively
> handed on to other code which the agent might want to be able to employ
> reflection. My problem is not with the functionality per se rather with
> the provenance of module M'.
> 
> As I understand the current situation (after conversations with Alan
> Bateman) all agent classes loaded from an agent jar -- whether the agent
> is deployed on the command line or dynamically, using the VM_Attach API
> -- will belong to the unnamed module _M. My problem turns on the
> question what is the relation between M' and _M?
> 
> In my case it is my agent code itself that needs to be able to perform
> reflective accesses. The agent does not need to provide any modules that
> belong to user code or JDK runtime code with the ability to perform
> reflective access. So, in my case it is only classes in _M that I want
> to be grant the opportunity to perform the reflective access.
> 
> Clearly, I don't want to make M' == _M i.e. to export P to all classes
> in the unnamed module _M. That would be a serious security flaw. Indeed,
> in general, the idea that an agent will take some module M' and provide
> all classes in M' with access to classes in package P is only going to
> work when the agent has some level of trust in the code in module M'.
> 
> I can imagine cases where, say, that might occur for a module that is
> not part of the agent per se -- e.g. module M' is part of some
> middleware layer whose behaviour has some guarantee of reliability.
> However, in most cases it is going to be the case that the code in
> module M' is directly related to the agent code and must be deployed
> along with the agent. It is highly unlikely that an agent will want to
> grant some arbitrary user module wholesale access to a package of some
> other module. Restricted export to the agent itself is certainly the
> only option in my case. So, with this proposed API my agent would itself
> need to provide a module M' and only need it in order to delegate
> requests which enable reflective member access. It is immaterial whether
> the reflective access itself is performed by the code in module M' or by
> agent code.
> 
> This presents two problems, one merely awkward, the other a
> show-stopper. My agent will need to provide two deliverables, the agent
> jar and a module. So, for command line use of the agent, my users will
> need to be able to configure deployment of both deliverables. This
> complicates usage and also requires different usage if users need to
> switch from a pre-Jigsaw to a Jigsaw-enabled JDK (it is common for
> Byteman to be used in environments where more than one JDK is
> installed). I may be able to mitigate this complexity using convenience
> scripts (as I have done already to deal with the difficulty many Byteman
> users face configuring the existing javaagent option).
> 
> Secondly, and far more importantly, there does not appear to be a way to
> deploy both the agent jar and an accompanying module dynamically. I
> don't see any option for adding the required agent module M' to the
> module path after start-up. This is a show-stopper because 99% of
> Byteman usage involves dynamic loading of the agent. I don't doubt that
> this will also be a show-stopper for many other agents.
> 
> What are the alternatives?
> 
> Perhaps Instrumentation needs to provide an API to add a module to the
> module path at runtime?
> 
> Alternatively, perhaps the proposed API could be used to define a new
> module at runtime as well as to redefine an existing one? That still
> leaves the question of how to populate that module with one or more classes.

Hi Andrew, for me it's another issue,
currently you can not use a modular jar with the -javaagent on the command line,
it's seems to be the root cause of your issue.

Now, the workaround,
there are two ways to create a module, one is to have a modular jar in the modulepath,
the other is to create a Layer to dynamically creates a module at runtime.
So currently, you can have the main instrumentation class in a default module,
this class can dynamically creates your module M', and add an export fom M' to M
each time you need to rewrite a class of a module M.

> 
> regards,
> 

regards,
Rémi

> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>