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
