[External] : Re: Verification in agent transformers

[coleen.phillimore at oracle.com]

On 3/7/25 1:00 PM, Ryan Ernst wrote:
> Hi Coleen,
>
> Thanks for the reply. The error was not in JDK code, it was in our transformation of the JDK code. We inserted a bad function call, passing an incompatible argument.
>
> Running verification on retransformClasses makes complete sense. But my question was about why the result of transformers are not verified when _not_ triggered by retransformClasses. That is, the same transformer that had the bug existed. When it is run via retransformClasses, it causes a VerifyError. But if it is run later in the program, the no verification error occurs, yet the transformer still produced broken bytecode.

I don't know what this last sentence means.  If the class is loaded and 
then linked, and is not on the bootstrap class loader, then it should be 
verified.  (?)
>
> Additionally, we noticed that the VerifyError had no message.

Yes, this is an unfortunate feature of errors during 
retransform/redefinition.  They lose their messages since JVMTI returns 
only JVMTI_ERROR_FAILS_VERIFICATION to the agent.

-Xlog:verification is the way to see what the specific error is.

>
>> [2025-03-06T20:03:17,159][WARN ][stderr ] [instance-0000000010] Caused by: java.lang.VerifyError
>> [2025-03-06T20:03:17,159][WARN ][stderr ] [instance-0000000010] at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)
>> [2025-03-06T20:03:17,160][WARN ][stderr ] [instance-0000000010] at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:221)
> However, when we captured the broken class bytes, if we run with `javap -verify` we get a clear error:
>
>> Bad type on operand stack in sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection::connect() @13 (javax/net/ssl/HttpsURLConnection is not assignable from sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection)
> Is there some difference in how verify is run between javap and at runtime that would account for an empty message?

It looks like javap can run the verifier directly and report the error.

Coleen

>
> Thanks
> Ryan
>
>> On Mar 7, 2025, at 9:43 AM, coleen.phillimore at oracle.com wrote:
>>
>>
>>
>> On 3/7/25 12:28 PM, Ryan Ernst wrote:
>>> Hi folks,
>>>
>>> In Elasticsearch we use an agent to instrument sensitive methods (ie a Security Manager replacement). Recently we found a VerifyError during instrumentation. The specific problem was an incompatible argument type to one of the methods we call from instrumented classes.
>>>
>>> The reason for this mail is to understand the context of why we only got the VerifyError in certain circumstances. The VerifyError tripped only on Java 24, and only when we call retransformClasses. When the transformer runs outside of retransformClasses, there is no VerifyError, yet the incompatible type existed (but it was unused, so did not trip a runtime problem, it was just a bad type sitting on the stack).
>>>
>>> What's the reason for only running verification when retransforming class, not on all transforms? I should note that this is for a JDK class, which as I understand are not verified upon loading normally?
>> Hi,
>>
>> We don't verify JDK classes because we provide and trust the implementation of these classes, but when you retransform these classes, we do not control what the redefinition will provide so verify them to maintain the security of the running application. This is a recent change in JDK 24, because the code intended to do this all along but there was a bug where it didn't.
>>
>> You can run -Xlog:verification to see the details of the VerifyError.  If it is bytecodes in the JDK and not ones provided by you, please report this to us so we can fix it.
>>
>> Thank you,
>> Coleen
>>
>>> Thanks!
>>> Ryan