Why having the wrong InnerClasses attribute is an issue for the VM ?

[forax at univ-mlv.fr]

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Lundi 30 Novembre 2020 13:44:32
> Objet: Re: Why having the wrong InnerClasses attribute is an issue for the VM ?

> On 30/11/2020 8:04 pm, forax at univ-mlv.fr wrote:
>> ----- Mail original -----
>>> De: "David Holmes" <david.holmes at oracle.com>
>>> À: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>>> <core-libs-dev at openjdk.java.net>
>>> Envoyé: Lundi 30 Novembre 2020 08:57:37
>>> Objet: Re: Why having the wrong InnerClasses attribute is an issue for the VM ?
>> 
>>> On 30/11/2020 5:08 pm, Remi Forax wrote:
>>>> I've forgotten a cast in an invokedynamic, hence a call to wrongTargetType,
>>>> but in order to create the error message, MethodType.toString(), getSimpleName()
>>>> is called and it fails because getDeclaringClass() verifies the InnerClasses
>>>> attribute.
>>>>
>>>> For me InnerClasses was just an attribute for javac not something the VM should
>>>> take care of,
>>>> it seems that the VM strongly verifies this attribute and i wonder what is the
>>>> reason behind that ?
>>>
>>>  From the VM code - InstanceKlass::compute_enclosing_class:
>>>
>>>    // Throws an exception if outer klass has not declared k as an inner
>>> klass
>>>    // We need evidence that each klass knows about the other, or else
>>>    // the system could allow a spoof of an inner class to gain access
>>> rights.
>>>    Reflection::check_for_inner_class(outer_klass, this,
>>> *inner_is_member, CHECK_NULL);
>> 
>> I don't understand how to spoof the InnerClasses attribute to gain access given
>> that the access rights are not based on the InnerClasses attribute.
> 
> Good point.
> 
> That aside though, how do you answer the is_top_level_class question if
> the enclosed and enclosing classes disagree about the relationship?

Good question too,
only by looking to the information stored in the class that can be top_level or not, i suppose. 

> 
> David
> -----
> 

Rémi

>>>
>>> David
>> 
>> Rémi
>> 
>>>
>>>> regards,
>>>> Rémi
>>>>
>>>> Exception in thread "main" java.lang.IncompatibleClassChangeError:
>>>> fr.umlv.transmogrif.ImplMap and
>>>> fr.umlv.transmogrif.ImplMap$Row/0x0000000801007400 disagree on InnerClasses
>>>> attribute
>>>>           at java.base/java.lang.Class.getDeclaringClass0(Native Method)
>>>>           at java.base/java.lang.Class.isTopLevelClass(Class.java:1970)
>>>>           at java.base/java.lang.Class.getSimpleBinaryName(Class.java:1955)
>>>>           at java.base/java.lang.Class.getSimpleName0(Class.java:1835)
>>>>           at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>>>>           at java.base/java.lang.Class.getSimpleName0(Class.java:1833)
>>>>           at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>>>>           at java.base/java.lang.invoke.MethodType.toString(MethodType.java:895)
>>>>           at java.base/java.lang.String.valueOf(String.java:3365)
>>>>           at java.base/java.lang.StringBuilder.append(StringBuilder.java:169)
>>>>           at
>>>>           java.base/java.lang.invoke.MethodHandle.standardString(MethodHandle.java:1611)
>>>>           at java.base/java.lang.invoke.MethodHandle.toString(MethodHandle.java:1608)
>>>>           at java.base/java.lang.String.valueOf(String.java:3365)
>>>>           at java.base/java.lang.invoke.CallSite.wrongTargetType(CallSite.java:203)
>>>>           at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:333)
>>>>           at
>>>>           java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280)
>>>>           at
>>>>           java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270)
>>>>           at fr.umlv.transmogrif.ImplMap/0x0000000801003c00.<init>(ImplMap.java:21)
> >>>           at fr.umlv.transmogrif.Main.main(Main.java:7)