RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK (original) (raw)
John Rose john.r.rose at oracle.com
Tue Mar 19 17:39:32 PDT 2013
- Previous message: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK
- Next message: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mar 19, 2013, at 1:14 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
javaClasses.hpp - MNCALLERSENSITIVE and MNSEARCHSUPERCLASSES have the same value. Should they be different?
1057 MNCALLERSENSITIVE = 0x00100000, // @CallerSensitive annotation detected 1061 MNSEARCHSUPERCLASSES = 0x00100000, // walk super classes
That's OK; they are used with different arguments, as the nearby comments point out.
method.hpp - Is callersensitive set to true if @CallerSensitive annotation is present and must be loaded by null class loader? Does it only check annotations if the class of that method is defined by the null class loader? Per our offline discussion early, classes loaded by the extension class loader may also be caller-sensitive.
Oops, that needs fixing.
For simplicity, I suggest you adjust the boolean 'privileged' that controls the ad hoc category of code that benefits from the annotation parsing. The important property of such code is that it is statically configured with the JVM, not dynamically loaded.
If a method calls Reflection.getCallerClass but its class is defined by other class loader (non-null and not extension class loader), your fix will throw InternalError with the same error message even if that method is annotated with @CS. Is there a way to improve the error message so that we can differentiate this case (i.e. @CS is present but not supported)?
Maybe not, if it would involve reparsing the annotations. The error message can mention that the offending method is off the BCP so that even if it were annotated the annotation would not count. We don't need a very user-friendly message here, as long as it points out that there is an offending off-label use of a JVM primitive. Nobody calls JVM_GetCallerClass by accident, and even if an end user is the unlucky discoverer, if the JVM message says "illegal internal method call" or some such, the bug should be clear enough.
jvm.cpp: have you considered adding a new entry point instead of having JVMGetCallerClass to behave differently depending on the existence of sun.reflect.CallerSensitive class? There are pros and cons of both options. Having a new entry point is cleaner and enables the opportunity to remove JVMGetCallerClass(int) in the future. I am fine with either approach but just to bring it up.
Good point. I'm fine with either option.
— John
- Previous message: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK
- Next message: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]