Accessing module internals from bytecode rewriting agent

[Martin Buchholz]

Thanks, all.  I should have remembered the special casing of
java.util.concurrent in checkUnprivilegedlookupClass.  It's surprising to
see different behavior crossing the java.util.concurrent boundary, as I
observed trying to access PriorityQueue.queue (fails!) vs.
PriorityBlockingQueue.queue (succeeds!).  Tools such as java agents should
have a single consistent mechanism that works for all target classes.

On Tue, Apr 25, 2017 at 1:19 AM, Andrew Dinn <adinn at redhat.com> wrote:

> On 25/04/17 07:22, Alan Bateman wrote:
> > On 25/04/2017 04:26, Martin Buchholz wrote:
> >
> >> :
> >>
> >> java.lang.IllegalArgumentException: illegal lookupClass: class
> >> java.util.PriorityQueue
> >>
> >> Bytecode rewriting agents have the power to inject code into classes;
> >> they
> >> should somehow also be able to reflectively inspect those same classes!
> >> But how?  We ran into similar problems trying to port java agents at
> >> Google
> >> to jdk9.
> > <snip>
> > On Byteman, Andrew Dinn has been working with us on jigsaw-dev on the
> > agent support. From the stack trace then I suspect the issue you are
> > running into is that Byteman has also changed to use the new reflection
> > API (java.lang.invoke) and is running into a long standing check to
> > prevent full power lookups to full privileged classes from leaking.
> > Andrew brought this up on jigsaw-dev [1] a few days ago and we could
> > probably move that thread to core-libs-dev.
>
> This discussion really ought to be happening on the Byteman forum but
> anyway ...
>
> Yes, Alan is right that this is exactly what is going on. Byteman on
> jdk9 (the 4.0.0-BETA release series) now uses method handles in place of
> reflection. Unfortunately, it is limited by a slightly arbitrary
> restriction on the use of method handles in java.* and sun.* packages (a
> blunt instrument to provide some security guarantees).
>
> This is being addressed on two fronts. I am in the process of adding
> unit tests to complete a workaround which remedies this problem by
> falling back to reflection in the specific cases where the restriction
> applies (yes, that means there is probably going to be another
> 4.0.0-BETA release before jdk9 goes live %-/ ).
>
> Meanwhile, Mandy Chung has kindly offered to look into the security
> considerations that are at play and come up with a less restrictive
> policy which enforces the security needs more accurately. At that point
> I will probably remove the fallback -- in part because I hope that by
> then both reflection and method handles will employ a common blacklist
> of inaccessible methods. I think it would make sense for them both to
> offer equivalent access and for that access to take security seriously.
>
> regards,
>
>
> 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
>