[External] : Re: Verification in agent transformers

[Ryan Ernst]

> If the class is loaded and then linked, and is not on the bootstrap class loader, then it should be verified.

I agree, but that’s not what we observed. We only see the VerifyError if retransformClasses is called. If instead the class is loaded after the transformer has been registered, no VerifyError occurs, even though the transformer produced technically broken bytecode (I say “technically” because although the parameter type was wrong, we never used the parameter in this method, so it didn’t actually cause any problems at runtime, it was just a bad reference on the stack that was ignored).

> On Mar 7, 2025, at 11:36 AM, coleen.phillimore at oracle.com wrote:
> 
> 
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20250307/3d0ae5c3/attachment.htm>