Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

[Peter Levart]

Hi Mandy,

On 05/02/2017 04:37 AM, Mandy Chung wrote:
> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.00/
>
> The big hammer check disallowing MethodHandles::lookup be called by system
> classes defined by the bootstrap class loader was added as defense-in-depth
> to prevent this caller-sensitive method being called from JDK internal classes
> via Method::invoke.  It was intended as a point fix and to be replaced
> with a long-term approach.  Lookup.privateLookupIn() returns a Lookup object
> and IAE is thrown if the lookup class is almost all java.* and sun.* [1].
> We should fix this in JDK 9.
>
> This patch replaces this restriction and now allow MethodHandles::lookup to
> be called statically by any code.  But disallow Method::invoke of
> MethodHandles.lookup from system classes defined by the bootstrap class loader
> e.g. java.base.  It is expected that no reflective call to
> MethodHandles::lookup is made by the system classes and so this approach
> would provide a better mechanism as a defense-in-depth.
>
> Mandy
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012267.html

I don't quite understand the need for bypassing the inflation of native 
into generated method accessor when the reflected method is a 
@CallerSensitive method which has a substitute method declared to be 
called by reflection (like with the MethodHandles.[reflected$]lookup() 
pair), in the following fragment of ReflectionFactory:

  179     public MethodAccessor newMethodAccessor(Method method) {
  180         checkInitted();
  181
  182         boolean noInflation = ReflectionFactory.noInflation;
  183         if (Reflection.isCallerSensitive(method)) {
  184             Method altMethod = findMethodForReflection(method);
  185             if (altMethod != null) {
  186                 method = altMethod;
  187                 noInflation = true;  // in this case only
  188             }
  189         }
  190
  191         if (noInflation && 
!ReflectUtil.isVMAnonymousClass(method.getDeclaringClass())) {
  192             return new MethodAccessorGenerator().
  193                 generateMethod(method.getDeclaringClass(),
  194                                method.getName(),
  195                                method.getParameterTypes(),
  196                                method.getReturnType(),
  197                                method.getExceptionTypes(),
  198                                method.getModifiers());
  199         } else {
  200             NativeMethodAccessorImpl acc =
  201                 new NativeMethodAccessorImpl(method);
  202             DelegatingMethodAccessorImpl res =
  203                 new DelegatingMethodAccessorImpl(acc);
  204             acc.setParent(res);
  205             return res;
  206         }
  207     }

Is DelegatingMethodAccessorImpl/NativeMethodAccessorImpl combo not 
treated correctly (i.e. skipped) by the Reflection.getCallerClass(), 
while generated MethodAccessorImpl subclass is?

Regards, Peter