We introduce Jinja, a Java-like programming language with a formal semantics designed to exhibit core features of the Java language architecture. Jinja is a compromise between realism of the language and tractability and clarity of the formal semantics. The following aspects are formalised: a big and a small step operational semantics for Jinja and a proof of their equivalence; a type system and a definite initialisation analysis; a type safety proof of the small step semantics; a virtual machine (JVM), its operational semantics and its type system; a type safety proof for the JVM; a bytecode verifier, i.e. data flow analyser for the JVM; a correctness proof of the bytecode verifier w.r.t. the type system; a compiler and a proof that it preserves semantics and well-typedness. The emphasis of this work is not on particular language features but on providing a unified model of the source language, the virtual machine and the compiler. The whole development has been carried out in the theorem prover Isabelle/HOL.

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...

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.

Virtual machines (vms) have enjoyed a resurgence as a way of allowing the same application program to be used across a range of computer systems. This flexibility comes from the abstraction that the vm provides over the native interface of a particular computer. However, this also means that the application is prevented from taking the features of particular physical machines into account in its implementation. This dissertation addresses the question of why, where and how it is useful, possible and practicable to provide an application with access to lower-level interfaces. It argues that many aspects of vm implementation can be devolved safely to untrusted applications and demonstrates this through a prototype which allows control over run-time compilation, object placement within the heap and thread scheduling. The proposed architecture separates these application-specific policy implementations from the application itself. This allows one application to be used with different policies on different systems and also allows nave or premature optimizations to be removed.

In previous work on SafeJava we presented a type system extension to the Java source language that statically prevents data races and deadlocks in multithreaded programs. SafeJava is expressive enough to support common programming patterns, its type checking is fast and scalable, and it requires little programming overhead. SafeJava thus offers a promising approach for making multithreaded programs more reliable. This paper presents a corresponding type system extension for the Java virtual machine language (JVML). We call the resulting language SafeJVML. Welltyped SafeJVML programs are guaranteed to be free of data races and deadlocks. Designing a corresponding type system for JVML is important because most Java code is shipped in the JVML format. Designing a corresponding type system for JVML is nontrivial because of important differences between Java and JVML. In particular, the absence of block structure in JVML programs and the fact that they do not use named local variables the way Java programs do make the type systems for Java and JVML significantly different. For example, verifying absence of races and deadlocks in JVML programs requires performing an alias analysis, something that was not necessary for verifying absence of races and deadlocks in Java programs. This paper presents static and dynamic semantics for SafeJVML. It also includes a proof that the SafeJVML type system is sound and that it prevents data races and deadlocks. To the best of our knowledge, this is the first type system for JVML that statically ensures absence of synchronization errors.

In this paper a, we present a dynamic semantics for the Java Virtual Machine Language (JVML). The semantics is specified in an operational style according to the syntactic structure of JVML programs. In order to ascribe meanings to threading, the semantics is made small-step and is structured in two layers: The first layer consists of judgements that capture the semantics of sequential JVML programs in isolation. The second layer consists of judgements that capture the parallel execution of JVML threads. The semantics presented in this paper is a faithful and formal transcription of JVML specification as described in [1]. Besides, we provide full account details for the most technical and tricky aspects of JVML such as multi-threading, synchronization, method invocations, exception handling, object creation, object’s fields manipulation, stack manipulation, local variable access, modifiers, etc. The presented semantics is, to the best of our knowledge, the first dynamic semantics of JVML that provides semantics for that many features within the same framework. a This research is funded under the NSERC DND partnership program in collaboration with DRDC Valcartier(Defence Research and Development Canada) and Bell Canada.

Abstract This paper presents an operational semantics for a subset of Java Card bytecode, focussing on aspects of the Java Card firewall, method invocation, field access, variable access, shareable objects and contexts. The goal is to provide a precise description of the Java Card firewall using standard tools from operational semantics. Such a description is necessary for formally arguing the correctness of tools for validating the security of Java Card applications. 1

This paper presents a constraint-based static analysis to prove security (confidentiality) properties of Java Card programs. We define a subset of the Java Card bytecode focussing on aspects of the Java Card firewall, method invocation, field access, variable access, shareable objects and contexts and present an analysis to compute an approximation of the set of possible value stored in each variable. To achieve this task, we introduce a new kind of constraints: quantified conditional constraints. This kind of constraints permits to generate the constraints for a program in a demand-driven fashion. In addition, it permit to model precisely the effects of the Java Card firewall by only producing a constraint if the corresponding operation is authorized by the firewall. The result of this analysis is a precise description of the object flow and of the security exceptions which can be thrown by the firewall.