Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Security and the class verifier

A look at the role played by the class verifier in the JVM's overall security model

By Bill Venners, JavaWorld.com, 10/01/97

  • Print
  • Feedback
.

Page 4 of 6

If an implementation does load classes earlier -- perhaps in an attempt to speed up the loading process -- then it must still give the impression that it is loading classes as late as possible. If, for example, a Java virtual machine discovers during early loading that it can't find a certain referenced class, it doesn't throw a "class definition not found" error until (and unless) the referenced class is used for the first time by the running program.

Phase two and dynamic linking
Phase two of class-file verification is really just part of the process of dynamic linking. When a class file is loaded, it contains symbolic references to other classes and their fields and methods. Dynamic linking is the process of resolving symbolic references into direct references. As the JVM executes bytecodes and encounters an opcode that, for the first time, uses a symbolic reference to another class, the virtual machine must resolve the symbolic reference. The virtual machine performs two basic tasks during resolution:

  • It finds the class being referenced (loading it if necessary).
  • It replaces the symbolic reference with a direct reference, such as a pointer or offset, to the class, field, or method.


The virtual machine remembers the direct reference so that if it encounters the same reference again later, it can immediately use the direct reference without needing to spend time resolving the symbolic reference again.

When the Java virtual machine resolves a symbolic reference, phase two of the class-file verifier makes sure the reference is valid. If the reference is not valid -- for instance, if the class cannot be loaded or if the class exists but doesn't contain the referenced field or method -- the class-file verifier throws an error.

As an example, consider a class named Volcano. If a method of class Volcano invokes a method in a class named Lava, the name and descriptor of the method in Lava are included as part of the binary data in the class file for Volcano. So, during the course of execution when Volcano's method first invokes Lava's method, the JVM makes sure a method exists in class Lava that has a name and descriptor that matches those expected by class Volcano. If the symbolic reference (class name, method name, and descriptor) is correct, the virtual machine replaces it with a direct reference, such as a pointer, which it will use from then on. But if the symbolic reference from class Volcano doesn't match any method in class Lava, phase two verification fails, and the JVM throws a "no such method" error.

Binary compatibility
The reason phase two of the class-file verifier must look at classes that refer to one another to make sure they are compatible is because Java programs are dynamically linked. Java compilers often will recompile classes that depend on a class you have changed, and in so doing, detect any incompatible changes at compile-time. But there may be times when your compiler doesn't recompile a dependent class. For example, if you are developing a large system, you will likely partition the various parts of the system into packages. If you compile each package separately, then a change to one class in a package would likely cause a recompilation of affected classes within that same package but not necessarily in any other package. Moreover, if you are using someone else's packages, especially if your program downloads class files from someone else's package across a network as it runs, it may be impossible for you to check for compatibility at compile-time. That's why phase two of the class-file verifier must check for compatibility at runtime.

  • Print
  • Feedback

Resources
  • The book The Java virtual machine Specification (http://www.aw.com/cp/lindholm-yellin.html), by Tim Lindholm and Frank Yellin (ISBN 0-201-63452-X), part of The Java Series (http://www.aw.com/cp/javaseries.html), from Addison-Wesley, is the definitive Java virtual machine reference.
  • Secure Computing with JavaNow and the Future (a whitepaper)http://www.javasoft.com/marketing/collateral/security.html
  • Applet Security FAQ
    http://www.javasoft.com/sfaq/
  • Low Level Security in Java, by Frank Yellin http://www.javasoft.com/sfaq/verifier.html
  • The Java Security Home Page
    http://www.javasoft.com/security/
  • See the Hostile Applets Home Page
    http://www.math.gatech.edu/~mladue/HostileApplets.html
  • The book Java SecurityHostile Applets, Holes, and Antidotes, by Dr. Gary McGraw and Ed Felton, gives a thorough analysis of security issues surrounding Java. http://www.rstcorp.com/java-security.html
  • An online version of the Java Language Specification is available at http://www.javasoft.com/docs/books/jls/html/index.html
  • Previous "Under The Hood" articles:
  • The Lean, Mean Virtual Machine -- Gives an introduction to the Java virtual machine.
  • The Java Class File Lifestyle -- Gives an overview of the Java class file, the file format into which all Java programs are compiled.
  • Java's Garbage- Collected Heap -- Gives an overview of garbage collection in general and the garbage-collected heap of the Java virtual machine in particular.
  • Bytecode Basics -- Introduces the bytecodes of the Java virtual machine, and discusses primitive types, conversion operations, and stack operations in particular.
  • Floating Point Arithmetic -- Describes the Java virtual machine's floating-point support and the bytecodes that perform floating point operations.
  • Logic and Arithmetic -- Describes the Java virtual machine's support for logical and integer arithmetic, and the related bytecodes.
  • Objects and Arrays -- Describes how the Java virtual machine deals with objects and arrays, and discusses the relevant bytecodes.
  • Exceptions -- Describes how the Java virtual machine deals with exceptions, and discusses the relevant bytecodes.
  • Try-Finally -- Describes how the Java virtual machine implements try-finally clauses, and discusses the relevant bytecodes.
  • Control Flow -- Describes how the Java virtual machine implements control flow and discusses the relevant bytecodes.
  • The Architecture of Aglets -- Describes the inner workings of aglets, IBM's autonomous Java-based software agent technology.
  • The Point of Aglets -- Analyzes the real-world utility of mobile agents such as aglets, IBM's autonomous Java- based software agent technology.
  • Method Invocation and Return -- Describes the four ways the Java virtual machine invokes methods, including the relevant bytecodes.
  • Thread Synchronization -- Shows how thread synchronization works in the Java virtual machine. Discusses the bytecodes for entering and exiting monitors.
  • Java's Security Architecture -- Gives an overview of the security model built into the JVM and looks at the JVM's built-in safety features.
  • Security and the Class Loader Architecture -- Describes class loaders and shows how the fit into Java's overall security model.