JDK-8330606 : Redefinition doesn't but should verify the new klass
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-04-18
  • Updated: 2025-03-31
  • Resolved: 2024-11-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24 b26Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8345899 :  
Description
Redefinition calls the verifier passing true for should_verify_class.

      RedefineVerifyMark rvm(the_class, scratch_class, state);
      Verifier::verify(scratch_class, true, THREAD);

But code within the verifier decides otherwise if the class belongs to the null class loader.  verify() calls

    Verifier::is_eligible_for_verification(InstanceKlass* klass, bool should_verify_class) {

which calls

    bool Verifier::should_verify_for(oop class_loader, bool should_verify_class) {
      return (class_loader == nullptr || !should_verify_class) ?
        BytecodeVerificationLocal : BytecodeVerificationRemote;
    }

So returns false for redefining java.lang.VerifyError for example.  Should that code be an && above ?

is_eligible_for_verification also has some exceptions, that for redefinition (java.lang.Class etc) should not be exceptions.  They should be verified if redefined.

-Xverify:all sets BytecodeVerificationLocal to true, but that's not what's needed for redefinition.  There should be a way to call the verifier with an always verify flag.
Comments
Changeset: 8f22db23 Branch: master Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2024-11-21 12:14:23 +0000 URL: https://git.openjdk.org/jdk/commit/8f22db23a50fe537d8ef369e92f0d5f9970d98f0
21-11-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22116 Date: 2024-11-14 19:03:18 +0000
14-11-2024

Linking JDK-8341094 where most of the cleanup described in this issue was done.
14-11-2024

`should_verify_class` is only used as a way to disable verification for a class that would otherwise be verified under BytecodeVerificationRemote. There is no way to force verification in the current scheme, except via BytecodeVerificationLocal. The basic logic is: if (BytecodeVerificationLocal) verify everything - no exceptions else if (BytecodeVerificationRemote) verify everything except classes loaded by the boot loader, and classes for which should_verify_class==false else don't do any verification My question about permission is whether the ability to redefine a core class implies a trusted source. If not then redefintiion does need a way to force verification on - but I'm not sure exactly where that would be enforced. How can you tell the classfile parsing is for redefinition?
24-04-2024

Boot loader classes if loaded from the boot loader aren't verified by default because the JDK provides known good bytecodes, but if you redefine these classes they should be verified, because the bytecodes can come from anywhere. I guess it depends on how much permission you need to redefine a class in java.lang. I would expect that the "should_verify_class" parameter would cause that to be true, but the function is written for verification for class loading, not redefinition.
23-04-2024

> Should that code be an && above ? No. Boot loader classes don't get verified by default, nor do classes for which should_verify_class is false, so in those two cases we only verify if BytecodeVerificationLocal is true (which it normally isn't).
22-04-2024

What permissions do you need to redefine a core class?
22-04-2024