[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR (S) 7127066: Class verifier accepts an invalid class file
From:       Lois Foltan <lois.foltan () oracle ! com>
Date:       2014-09-04 13:23:38
Message-ID: 540867DA.9010004 () oracle ! com
[Download RAW message or body]

Hi Harold,
I have reviewed, looks good.
Thanks,
Lois

On 8/29/2014 8:41 AM, harold seigel wrote:
> Hi,
>
> Resending this RFR with a description of the bug because the bug is 
> not accessible to all reviewers.
>
> The bug is that the verifier accepts a class that it should not. 
> Verification should fail because, in this case, the stack map at a TRY 
> block's astore_2 instruction does have enough locals to satisfy the 
> stack map for one of its covering exception handlers. However, the 
> HotSpot VM class verifier does not detect the problem, and loads the 
> class.
>
> The root cause of this issue is that the verifier is using the result 
> type state from the astore_2 instruction, instead of correctly using 
> the incoming type state, when checking for a compatible type-state for 
> the exception handler. This is not-to-spec, as JVMS 8 does indicate 
> that the instruction's incoming type state (with expression stack 
> modification) should be used for type checking the covering exception 
> handlers.
>
> I hope this compensates for the inaccessibility of the bug.
>
> Thanks, Harold
>
> On 8/28/2014 5:07 PM, harold seigel wrote:
>> Hi,
>>
>> Please review this small verifier fix for bug JDK-7127066.  The 
>> change fixes the problem by doing the exception handler type state 
>> verification for byetcodes, such as astore, that modify the type 
>> state, before the type state gets modified.
>>
>> bug:  https://bugs.openjdk.java.net/browse/JDK-7127066
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_7127066/
>>
>> The fix was tested with JCK lang, vm, and api/java_lang tests, ute 
>> quick tests, ute split_verifier tests, hotspot JTREG tests, and the 
>> test case provided in the bug.
>>
>> Thanks, Harold
>

[prev in list] [next in list] [prev in thread] [next in thread]