Re: NOP ATHROW hack defeated !

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.

Eric

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

-- 
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