Toward a provably-correct implementation of the JVM bytecode verifier

Language-Based Security for Malicious Mobile Code

“…For example, because JVML provides no support for tail calls, it makes a poor target language when compiling functional languages. Finally, the official specification of the JVML type system is an informal English description and provides no model for ensuring soundness, though recent work has provided formal specifications of important fragments of the language [48,10,43,20,17,18,40]. Even if such formal models can be constructed, it would be a daunting task to prove the correctness of a production JVML verifier, JIT compiler, and runtime.…”

A Formal Executable Semantics of the JavaCard Platform

“…Thus, we see our work as complementary to theirs and as further evidence that, as suggested in [25], "machine-checking the design of a non-trivial programming language has become a reality". Other partial formalisations of the Java and JavaCard platforms are reported by Y. Bertot [5] (object initialisation in Coq after [13]), by R. Cohen [10] (defensive JVM in ACL2), by T. Jensen and co-authors [29] (converter in Coq), by J.-L. Lanet and A. Requet [20] (JCVM in B), by Z. Qian and co-workers [9] (JVM and BCV in Specware) and by D. Syme [31] (operational semantics, type system and type soundness of source Java in DECLARE).…”

Verified Bytecode Verifiers

“…Work towards a verified implementation in the Specware system is sketched by Coglio et al [3]. Although we share the latticetheoretic foundations with this work and it appears to consider roughly the same instruction set, it is otherwise quite different: whereas we solve the data flow problem directly, they generate constraints to be solved separately, which is not described.…”

“…For reasons discussed already towards the end of §3. 3 we also require that the functions step and succs do not lead outside the semilattice carrier A:…”