Why having the wrong InnerClasses attribute is an issue for the VM ?
David Holmes
david.holmes at oracle.com
Mon Nov 30 12:44:32 UTC 2020
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?
David
-----
>>
>> 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)
More information about the core-libs-dev
mailing list