Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Throw IllegalAccessError on resolution with inaccessible types #2675

Merged
merged 1 commit into from
Sep 14, 2018

Conversation

pdbain-ibm
Copy link
Contributor

Make OpenJ9 behaviour compliant to the reference implementation.

@pdbain-ibm pdbain-ibm force-pushed the methodhandle branch 2 times, most recently from fc656ef to dbad1c2 Compare August 22, 2018 14:54
@@ -2503,6 +2510,8 @@ public static MethodHandle varHandleInvoker(VarHandle.AccessMode accessMode, Met
public static MethodHandle throwException(Class<?> returnType, Class<? extends Throwable> exception) {
MethodType realType = MethodType.methodType(returnType, exception);
MethodHandle handle;
System.out.println("PDB_DEBUG throwException returnType="+returnType
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This appears a WIP.

Map<CacheKey, WeakReference<MethodHandle>> cache = HandleCache.getStaticCache(clazz);
MethodHandle handle = HandleCache.getMethodFromPerClassCache(cache, methodName, type);
if (handle == null) {
initCheck(methodName);
handle = new DirectHandle(clazz, methodName, type, MethodHandle.KIND_STATIC, null);
handle = HandleCache.putMethodInPerClassCache(cache, methodName, type, convertToVarargsIfRequired(handle));
}
checkAccess(handle, false);
checkAccess(handle, true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pls explain the reason that skipAccessCheckPara need to be changed to true.

Copy link
Member

@DanHeidinga DanHeidinga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem like the right approach as it applies access checking to the MethodType inconsistently.

The MT being passed in here may have been created somewhere else that did have access to the all the types in that case, the lookup should fail with NoSuchMethodError or similar.

The place to change is the callers of MethodType.vmResolveFromMethodDescriptorString() to do the additional access checking. Most callers - ie: the resolvesupport.cpp code which calls this through sendFromMethodDescriptorString - already do the access checking in native code. There are just 1, mayne 2, places in java code that need to be updated.

@pdbain-ibm pdbain-ibm force-pushed the methodhandle branch 2 times, most recently from e42d49f to 117e994 Compare August 23, 2018 13:47
@pdbain-ibm
Copy link
Contributor Author

@DanHeidinga I reworked per
#2675 (review) to do the checking in MethodHandle.sendResolveMethodHandle() and MethodHandle.resolveInvokeDynamic() as a separate commit and reran the failing test suite. If that is acceptable I will squash it.

/* Can never happen */
throw new UnsupportedOperationException();
}
if (!Objects.nonNull(type)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

type can never be null here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar concern here - the access check should precede the MH lookup

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

type can never be null here.: type is initialized to null and cases 1-4 do not set it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the access check should precede the MH lookup: moving the checks into the various cases.

@@ -855,8 +855,16 @@ private static final MethodHandle resolveInvokeDynamic(long j9class, String name
throw new NullPointerException(Msg.getString("K05cd", classObject.toString(), bsmIndex)); //$NON-NLS-1$
}
Object[] staticArgs = new Object[BSM_OPTIONAL_ARGUMENTS_START_INDEX + bsmArgCount];
final MethodHandles.Lookup lookup = new MethodHandles.Lookup(classObject, false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The access check should be moved to immediately after the vmResolveFromMethodDescriptorString call so that access exceptions occur before any exceptions getting the BSM

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do.

@pdbain-ibm
Copy link
Contributor Author

Updated and commits squashed.

switch(cpRefKind){
case 1: /* getField */
return lookup.findGetter(referenceClazz, name, resolveFieldHandleHelper(typeDescriptor, loader));
result = lookup.findGetter(referenceClazz, name, resolveFieldHandleHelper(typeDescriptor, loader));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolveFieldHandleHelper(typeDescriptor, loader) will have the same issue as vmResolveFromMethodDescriptorString and will also need the accessCheck.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. resolveFieldHandleHelper() changed to take a Lookup object to do the test.

	private static final Class<?> resolveFieldHandleHelper(String typeDescriptor, Lookup lookup, ClassLoader loader) throws Throwable {
		MethodType mt = MethodType.vmResolveFromMethodDescriptorString()...
		lookup.accessCheckArgRetTypes(mt);
		return mt.parameterType(0);

… inaccessible types

Signed-off-by: Peter Bain <peter_bain@ca.ibm.com>
@pdbain-ibm pdbain-ibm changed the title Throw IllegalAccessError if we call findStatic with illegal signature Throw IllegalAccessError on resolution with inaccessible types Aug 23, 2018
@pdbain-ibm
Copy link
Contributor Author

@DanHeidinga do you have further comments on this pull request?
Thanks
-p

Copy link
Member

@DanHeidinga DanHeidinga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@DanHeidinga
Copy link
Member

Jenkins test sanity xlinux jdk10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants