#ReflectiveAccessByInstrumentationAgents

[Alan Bateman]

This is a follow-up to Andrew Dinn's mail to jpms-spec-comments [1] on 
the topic of instrumentation. Andrew confirmed that he is okay to move 
follow-up discussion here.

Andrew - I think it would be useful if you could set the scene and 
describe some of the scenarios where the Byteman instrumentation can 
potentially fail at runtime. I get the impression from the mail that you 
weren't seeing any issues at the time but this may have been early 
experimentation.

A starting question might be whether Byteman can potentially inject code 
into module A with calls into non-exported types in module B? Does this 
arise with fault injection?

I may be reading too much into this but I would assume Byteman is 
already doing some checking to ensure that the B types are visible from 
A. If you add support for modules to Byteman then the scenario means 
thinking about accessibility too. For the access to succeed then it 
means that (1) module A reads module B, and (2) that B exports the 
package to A.

For (1) then there are APIs in both java.lang.instrument and JNI and so 
a JVM TI or java Byteman can do this. Alternatively it can instrument 
code in A to have A reflectively read B.

For (2) then then there aren't API to break encapsulation but Byteman 
could instrument code in B to use the reflective APIs to export the 
package to A. This is runtime equivalent of the -XaddExports command 
line option.

Your mail mentions setAccessible which suggests it might be actually be 
injecting code that uses core reflection rather than static references 
to types in B. There is a mention of accessing private members in your 
mail so maybe it uses core reflection for this scenario because such 
access is not allowed with bytecode???  If this is the case then you'll 
still need (2).

Another question is about your comment on "get-out for JVM TI agent 
code".  JVM TI agents are native agents and so are using JNI where there 
isn't any access checks. I don't expect there are issues there but it 
would be good to clarify what you may have meant at the time.

Thanks,

-Alan

[1] 
http://mail.openjdk.java.net/pipermail/jpms-spec-comments/2016-March/000020.html