Re: NOP ATHROW hack defeated !

On 04/30/2011 10:20 AM, Eric Bruneton wrote:
> 29/04/2011 03:04, Rémi Forax wrote:
>> Charles Nutter (a JRuby guy) was able to generate a code that defeat
>> the infamous NOP ... ATHROW hack.
>>
>> see http://asm.ow2.org/doc/developer-guide.html#deadcode
>> for the background.
>>
>> Basically, when a code is dead, not reachable, ASM replaces the
>> offending code by
>> NOP ... ATHROW and generate a dedicated stackmap: [] 
>> [java/lang/Throwable].
>> But if the unreachable code is in a try/catch, we create a path where no
>> local variable
>> are available anymore. So the split verifier will reject the bytecode if
>> a local variable is used in the exception handler of the try/catch.
>>
>> The program below generates a bytecode which is rejected by the split
>> verifier.
>> [forax@localhost asm4-test]$ java deadcode
>> Exception in thread "main" java.lang.VerifyError: Stack map does not
>> match the one at exception handler 7 in method
>> deadcode.foo(Ljava/lang/Object;)V at offset 3
>> at java.lang.Class.getDeclaredMethods0(Native Method)
>> at java.lang.Class.privateGetDeclaredMethods(Class.java:2440)
>> at java.lang.Class.getMethod0(Class.java:2683)
>> at java.lang.Class.getMethod(Class.java:1618)
>> at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:484)
>> at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:476)
>>
>>
>> Eric, do you see a solution for that ?
>
> I think we can find which locals to put in the stackmap frame 
> generated for a dead block by using the locals from the first frame of 
> the innermost exception handler for this block(*) (if any). Using the 
> innermost handler is necessary to get the most specific types for 
> these locals (the other handlers will necessarily have these types or 
> super types of these types in their stackmap frames, since they handle 
> more code). Also, since dead blocks are handled after the fix point 
> algorithm is finished, we have the final frames for the exception 
> handlers at this point.
>
> The only problem is that exception handlers do not have to be properly 
> nested (nothing enforces this in the specification, although compilers 
> always generate nested handlers because Java try/catch are nested by 
> construction). And in this case the "innermost handler" is not well 
> defined.

I also know JITs of well known VMs that does like un-nested handlers.

>
> Eric
>
> * in fact we may need to used the innermost *reachable* exception 
> handler (a handler can be itself unreachable).

Rémi

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws