RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK

[Peter Levart]

On 03/21/2013 07:11 PM, Mandy Chung wrote:
> Hi Peter,
>
> On 3/20/2013 2:33 AM, Peter Levart wrote:
>> Hi,
>>
>> If I understand correctly, sun.reflect.Reflection.getCallerClass(int) 
>> will not be usable by non-system code any more. I know it's not a 
>> public API, but it's useful in some situations (not security-related) 
>> and there's no public API for that functionality.
>>
>
> Do you have any example of existing use of Reflection.getCallerClass 
> to find immediate caller class?  or does it need to walk the stack? 
> That'd be useful.

I have seen a utility that uses it to establish the context (package and 
ClassLoader) of where to start searching for resources for GUI 
components construction. And a utility that wraps Class.forName(String) 
- specifying Class.forName(name, true, 
Reflection.getCallerClass(2).getClassLoader()) instead to use the 
caller's class loader to load the class...

Usually it is only necessary to get the immediate caller.

>
>> Is there a reason to not "unofficially" support also classes with @CS 
>> annotated methods and which are not loaded by bootstrap or extension 
>> class-loader ?
>
> We expect that most of the caller-sensitive cases are in the JDK and 
> should be rare for non-system libraries to have caller-sensitive 
> code.  It'd be good to understand the use cases and the requirements 
> to determine the appropriate support for it.

Ok, but why limit? Is it an optimization?

Is it for security? For example: one might think that creating an 
anonymous class and holding a j.l.Class reference somewhere safe is 
enough for safety, so the class itself could have public API. Now if an 
untrusted callback object is passed to the code of such class and it is 
invoked from within that code, the anonymous class can get "revealed" to 
the untrusted code which can use it's public API to invoke it. Are there 
any other implications of allowing non-system code to get the caller?

Regards, Peter

>
> Mandy
>
>>
>> Regards, Peter
>>
>> On 03/15/2013 04:31 AM, Christian Thalinger wrote:
>>> [This is the HotSpot part of JEP 176]
>>>
>>> http://cr.openjdk.java.net/~twisti/7198429
>>>
>>> 7198429: need checked categorization of caller-sensitive methods in 
>>> the JDK
>>> Reviewed-by:
>>>
>>> More information in JEP 176:
>>>
>>> http://openjdk.java.net/jeps/176
>>>
>>> src/share/vm/ci/ciMethod.cpp
>>> src/share/vm/ci/ciMethod.hpp
>>> src/share/vm/classfile/classFileParser.cpp
>>> src/share/vm/classfile/classFileParser.hpp
>>> src/share/vm/classfile/javaClasses.hpp
>>> src/share/vm/classfile/systemDictionary.hpp
>>> src/share/vm/classfile/vmSymbols.hpp
>>> src/share/vm/oops/method.cpp
>>> src/share/vm/oops/method.hpp
>>> src/share/vm/opto/library_call.cpp
>>> src/share/vm/prims/jvm.cpp
>>> src/share/vm/prims/methodHandles.cpp
>>> src/share/vm/prims/unsafe.cpp
>>> src/share/vm/runtime/vframe.cpp
>>> src/share/vm/runtime/vframe.hpp
>>>
>>
>