Verification in Java (JVM)

After the class loader in the JVM loads the byte code of .class file to the machine the Bytecode is first checked for validity by the verifier and this process is called as verification. The verifier performs as much checking as possible at the Linking so that expensive operation performed by the interpreter at the run time can be eliminated. It enhances the performances of the interpreter.

Some of the checks that verifier performs:

  • Uninitialized Variables
  • Access rules for private data and methods are not violated.
  • Method calls match the object Reference.
  • There are no operand stack overflows or underflows.
  • The arguments to all the Java Virtual Machine instructions are of valid types.
  • Ensuring that final classes are not subclassed and that final methods are not overridden
  • Checking that all field references and method references have valid names, valid classes, and a valid type descriptor. (source)

If any of these checks fails JVM throws a “java.lang.VerifyError” error. However, we can disable these checks using



java -noverify VerifyGeekFile

One might think how a program could have been manipulated since compiler checks these above validations before generating .class file. But the class file is vulnerable to change before JVM loads it. The bytecode used in the class file is well documented and someone having some knowledge of hex can change the values of hex codes in the .class file thus change the behavior of the program.
For example : The Applets in the web browsers do not download source code instead they download precompiled class files. The browser on your computer determines whether this class file is trustworthy to run or the file have been exploited by a “hostile compiler”.

Consider this Simple Program

filter_none

edit
close

play_arrow

link
brightness_4
code

// A Java program to demonstrate working
// of the verification process
  
class VerifyGeekFile
{
    // your initial bank bal
    private float bal;
  
    // Method to deposit money
    float depositBalance(int bal)
    {
        int myBal = bal;
        this.bal += myBal;
        return this.bal;
    }
  
    // Driver Method
    public static void main(String[] args)
    {
        VerifyGeekFile obj = new VerifyGeekFile();
        System.out.println(obj.depositBalance(4000));
    }
}

chevron_right


Output
 4000.0

Then execute this in command line to see the byte code in mnemonic form:-

javap -c VerifyGeekFile

Output :

float depositBalance(int);
    Code:
       0: iload_1
       1: istore_2
       2: aload_0
       3: dup
       4: getfield      #2                  // Field bal:F
       7: iload_2
       8: i2f
       9: fadd
      10: putfield      #2                  // Field bal:F
      13: aload_0
      14: getfield      #2                  // Field bal:F
      17: freturn

Here if we change the initial value of myBal or leave it uninitialized using a hex editor, unexpected results are returned. Java verification process protects us from all of these pitfalls.

References:
http://www.informit.com/articles/article.aspx?p=1187967&seqNum=2
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.10



My Personal Notes arrow_drop_up

Check out this Author's contributed articles.

If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.



Improved By : Akanksha_Rai



Article Tags :
Practice Tags :


Be the First to upvote.


Please write to us at contribute@geeksforgeeks.org to report any issue with the above content.