As part of the class loading process, a thorough verification
of the bytecodes takes place to insure that the file holds a valid
Java class and does not break any of the rules for class behavior.
The class verification procedure includes basically four steps
(though individual JVMs may mix and merge these steps) that check
examination of the file to see that it form obeys the basic
requirements of a class file such as beginning with the magic
for Java classes, the length of the file and subsections should
be consistent, the version numbers are in the range for the
JVM, and so forth.
- Semantics - look at individual
parts of the class, such as methods and fields, to check that
they are well-formed and obey the requirements on the data types
- Bytecode - first check the
bytecodes to insure that the instructions are valid, in the right
order, obey the rules on types and numbers of operands, and so
forth. Then a "data-flow analysis" runs to insure that
alternate paths to a given instruction always result in a consistent
state (for example, the operands should receive assigned values.)
- Symbolic references - this
step replaces symbolic references, such as the names of other
classes methods and fields, with direct references for the JVM
execution. This is part of the dynamic binding (or linking)
process in which classes are not linked together until they run
in the JVM. If a referenced class is not yet load, the JVM, depending
on its designers, may load it at this point or wait until it is
actually needed in the program processsing. If a class has changed
and, for example, a method signature changed from the way it was
invoked, the JVM will throw an exception and stop the program.
So we see that deliberately creating Java bytecodes to bypass Java
security restrictions requires surmounting very tough entrance roadblocks.
If a class follows all of the bytecode rules and loads satisfactorily,
what prevents, say, an applet from executing valid but pathological
activities such as filling a disk with files or reading files it
shouldn't? This is where the SecurityManager
(see next page) object
comes into the picture.
References & Web
Most recent update: Oct. 5, 2005