Java Reference
In-Depth Information
become close to the default platform for new object code. That in itself makes the JVM inter-
esting. But there are reasons for the JVM being the runtime environment of choice for such
new code, and understanding what those are will help us gain a better understanding of the
good parts of the JVM.
Security
One of the great things that the JVM provides is enhanced security, both for the programs run-
ning in the virtual machine and for the machine on which the JVM is executing. Since a Java
program runs inside a JVM, there is an extra layer between the program and the computer.
This extra layer has a lot of checks on the code, and isolates the code further from other code
running on the physical machine. This lets the JVM act as a security monitor, and a lot of what
the JVM does is tied to this role.
One of the ways that the JVM provides security is that it verifies all the code run in the JVM
prior to loading that code. As part of loading a Java class into a running program, the JVM
goes through a set of checks on the code. The highest level explanation is that the verifier
makes sure that the bytecodes could have been produced by a conformant Java language com-
piler. In detail, this means that no types have been coerced in an incorrect way, there are no
jumps to random parts of the code, and all the sequences of bytecodes make sense.
There has been considerable research and controversy over whether or not the verification
performed by the JVM before classes are loaded is really sufficient to give complete security.
Most of the common mechanisms that can be used to build malware (such as overwriting ar-
rays or doing coercions on types) are not allowed in code loaded into the JVM, but there are
occasional claims that new exploits have been found that may leak information or otherwise
provide a handle for bad actors.
That there might be such exploits becomes much less surprising when one understands the
origin of the verifier in the JVM. The original intention of the verifier was not to protect
against attacks in code, but rather to make sure that there were fewer bugs in code. The Java
language and environment was first invented to provide a programming environment for em-
bedded devices. Such devices are widely deployed (when successful) and hard to patch, and
the owners of such devices expect the devices to work (unlike users of software, who have
learned better). Most of the features that were originally seen as part of the Java security mod-
el (garbage collection, references rather than pointers, bounds checking on arrays) were not
introduced into the language to avoid malicious code, but to avoid buggy code. It was then
