Verification in agent transformers

[Ryan Ernst]

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.

Additionally, we noticed that the VerifyError had no message. 

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

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
>