Java is typically compiled into an intermediate language, JVML, that is interpreted by the Java Virtual Machine. Because mobile JVML code is not always trusted, a bytecode verifier enforces static constraints that prevent various dynamic errors. Given the importance of the bytecode verifier for security, its current descriptions are inadequate. This paper proposes using typing rules to describe the bytecode verifier because they are more precise than prose, clearer than code, and easier to reason about than either. JVML has a subroutine construct used for the compilation of Java’s try-finally statement. Subroutines are a major source of complexity for the bytecode verifier because they are not obviously last-in/first-out and because they require a kind of polymorphism. Focusing on subroutines, we isolate an interesting, small subset of JVML. We give typing rules for this subset and prove their correctness. Our type system constitutes a sound basis for bytecode verification and a rational reconstruction of a delicate part of Sun’s bytecode verifier. 1 Bytecode verification and typing rules The Java language is typically compiled into an intermediate language that is interpreted by the Java Virtual Machine (VM) [LY96]. This intermediate language, which we call JVML, is an object-oriented language similar to Java. Its features include packages, classes with single inheritance, and interfaces with multiple inheritance. However, unlike method bodies in Java, method bodies in JVML are sequences of bytecode instructions. These instructions are fairly high-level but, compared to the structured statements used in Java, they are more compact and easier to interpret. JVML code is often shipped across networks to Java VMs embedded in web browsers and other applications. Mobile JVML code is not always trusted by the VM that receives it. Therefore, a bytecode verifier enforces static constraints on mobile JVML code. These constraints rule out type errors (such as dereferencing an integer), access control violations (such as accessing a private method from outside its class),

In the standard Java implementation, a Java language program is compiled to Java bytecode. This bytecode may be sent across the network to another site, where it is then interpreted by the Java Virtual Machine. Since bytecode may be written by hand, or corrupted during network transmission, the Java Virtual Machine contains a bytecode verifier that performs a number of consistency checks before code is interpreted. As illustrated by previous attacks on the Java Virtual Machine, these tests, which include type correctness, are critical for system security. In order to analyze existing bytecode verifiers and to understand the properties that should be verified, we develop a precise specification of statically-correct Java bytecode, in the form of a type system. Our focus in this paper is a subset of the bytecode language dealing with object creation and initialization. For this subset, we prove that for every Java bytecode program that satisfies our typing constraints, every object is in...

This technical report describes a machine checked proof of the type soundness of a subset of the Java language called Java S . A formal semantics for this subset has been developed by Drossopoulou and Eisenbach, and they have sketched an outline of the type soundness proof. The formulation developed here complements their written semantics and proof by correcting and clarifying significant details; and it demonstrates the utility of formal, machine checking when exploring a large and detailed proof based on operational semantics. The development also serves as a case study in the application of `declarative' proof techniques to a major property of an operational system. Contents 1 Introduction 2 1.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 What is Type Soundness for Java? . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 The Tool: DECLARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Outl...

This paper presents a sound type system for a large subset of the Java bytecode language including classes, interfaces, constructors, methods, exceptions, and bytecode subroutines. This work serves as the foundation for developing a formal specification of the bytecode language and the Java Virtual Machine's bytecode verifier. We also describe a prototype implementation of a type checker for our system and discuss some of the other applications of this work. For example, we show how to extend our work to examine other program properties, such as the correct use of object locks. 1 Introduction The bytecode language, which we refer to as JVML, is the platform independent representation of compiled Java programs. In order to prevent devious applets from causing security problems stemming from type errors, the Java Virtual Machine bytecode verifier performs a number of consistency checks on bytecode before it is executed [LY96]. This paper presents a type system that may serve as the fou...

To study the properties of the Java Virtual Machine(JVM) and Java programs, our research group has produced a series of JVM models written in a functional subset of Common Lisp. In this paper, we present our most complete JVM model from this series, namely, M6, which is derived from a careful study of the J2ME KVM[16] implementation. On the one hand, our JVM model is a conventional machine emulator. M6 models accurately almost all aspects of the KVM implementation, including the dynamic class loading, class initialization and synchronization via monitors. It executes most J2ME Java programs that do not use any I/O or floating point operations. Engineers may consider M6 an implementation of the JVM. It is implemented with around 10K lines in 20+ modules. On the other hand, M6 is a novel model that allows for analytical reasoning besides conventional testing. M6 is written in an applicative (side-effect free) subset of Common Lisp, for which we have given precise meaning in terms of axioms and inference rules. A property of M6 can be expressed as a formula. Rules of interference can be used analytically to derive properties of M6 and the Java programs that run on the model, using a mechanical theorem prover. We argue

The Java Virtual Machine executes bytecode programs that may have been sent from other, possibly untrusted, locations on the network. Since the transmitted code may be written by a malicious party or corrupted during network transmission, the Java Virtual Machine contains a bytecode verifier to check the code for type errors before it is run. As illustrated by reported attacks on Java run-time systems, the verifier is essential for system security. However, no formal specification of the bytecode verifier exists in the Java Virtual Machine Specification published by Sun. In this paper, we develop such a specification in the form of a type system for a subset of the bytecode language. The subset includes classes, interfaces, constructors, methods, exceptions, and bytecode subroutines. We also present a type checking algorithm and prototype bytecode verifier implementation, and we conclude by discussing other applications of this work. For example, we show how to extend our formal system to check other program properties, such as the correct use of object locks.

We give a formal specification of the dynamic semantics of Java byte-code, in the form of an operational semantics for the Java Virtual Machine (JVM). For each JVM instruction we give a rule describing the instruction's effect on the machine state, and the conditions under which the instruction will execute without error. This paper outlines the formalization of the JVM machine state, and illustrates our specification approach with a few select JVM instructions. Our full specification, covering the entire JVM instruction instruction set except for synchronization instructions, is available in [2]. Keywords: Java, JVM, formal specification, semantics. 1

Java bytecode provides a portable representation for programs that allows executable content to be embedded in web pages, transferred across a network, and executed on a remote user's machine. Features like these provide many new opportunities for developers, but special precautions must be taken to protect users from badly-behaved programs, which might otherwise destroy valuable data or compromise their privacy. To avoid such problems, bytecode programs from untrusted sources must be verified before they are used. If a program passes, then it should be well-behaved, and should not be able to subvert the other security mechanisms of the Java platform. However, if a program fails, then it will be rejected. Clearly, to be sure that it is effective, we need a precise way to understand bytecode verification. This paper describes the main features of a formal specification for Java bytecode that allows us to reason about the correctness of Java implementations, and to guarantee safety prope...

We exhibit a grey area in the specification of Java and of its implementation through the Java Virtual Machine (JVM): the treatment of initialization of classes and interfaces. We report the result of our experiments with different implementations of Java, which confirm the theoretical prediction of our work on mathematical models for Java [3] and the JVM [2], namely that the designers of Java and the JVM have used notions of initialization which do not match and which afflict the portability of Java programs. We show also that concurrent initialization may deadlock and that various current Java compilers violate the initialization semantics through standard optimization techniques.

We provide a modular high-level definition of the Java Virtual Machine (JVM) architecture. We decompose the machine into three components -- the loader, the bytecode verifier and the interpreter -- each for a hierarchy of four stepwise refined JVM program layers. These layers naturally correspond to the structuring of Java into sublanguages with imperative, procedural, object-oriented and exception handling features. We give our definitions in terms of Abstract State Machines, which have a simple but precise semantic foundation. As a consequence our JVM models can be verified and validated by machine supported mathematical analysis and standard simulation techniques. Furthermore, due to their abstract nature, the models can serve as a platform independent basis for the evaluation and comparison of different JVM implementations.