Results 1 
9 of
9
Partial Functions in ACL2
 Journal of Automated Reasoning
"... We describe a macro for introducing \partial functions" into ACL2, i.e., functions not dened everywhere. The function \denitions" are actually admitted via the encapsulation principle. We discuss the basic issues surrounding partial functions in ACL2 and illustrate theorems that can be proved ab ..."
Abstract

Cited by 31 (7 self)
 Add to MetaCart
We describe a macro for introducing \partial functions" into ACL2, i.e., functions not dened everywhere. The function \denitions" are actually admitted via the encapsulation principle. We discuss the basic issues surrounding partial functions in ACL2 and illustrate theorems that can be proved about such functions.
Proving theorems about Java and the JVM with ACL2
 Models, Algebras and Logic of Engineering Software
, 2003
"... We describe a methodology for proving theorems mechanically about Java methods. The theorem prover used is the ACL2 system, an industrialstrength version of the BoyerMoore theorem prover. An operational semantics for a substantial subset of the Java Virtual Machine (JVM) has been defined in ACL2. ..."
Abstract

Cited by 18 (9 self)
 Add to MetaCart
We describe a methodology for proving theorems mechanically about Java methods. The theorem prover used is the ACL2 system, an industrialstrength version of the BoyerMoore theorem prover. An operational semantics for a substantial subset of the Java Virtual Machine (JVM) has been defined in ACL2. Theorems are proved about Java methods and classes by compiling them with javac and then proving the corresponding theorem about the JVM. Certain automatically applied strategies are implemented with rewrite rules (and other proofguiding pragmas) in ACL2 “books” to control the theorem prover when operating on problems involving the JVM model. The Java Virtual Machine or JVM [27] is the basic abstraction Java [17] implementors are expected to respect. We speculate that the JVM is an appropriate level of abstraction at which to model Java programs with the intention of mechanically verifying their properties. The most complex features of the Java subset we handle – construction and initialization of new objects, synchronization, thread management, and virtual method invocation – are all supported directly and with full abstraction as single atomic instructions in the JVM. The complexity of verifying JVM bytecode program stems from the complexity of Java’s semantics, not
The Operational Semantics of a Java Secure Processor
 Declarative systems and Software Engineering group, University of Southampton,Highfield, Southampton SO17 1BJ
, 1998
"... A formal specification of a Java Secure Processor is presented, which is mechanically checked for type consistency, well formedness and operational conservativity. The specification is executable and it is used to animate and study the behaviour of sample Java programs. ..."
Abstract

Cited by 13 (1 self)
 Add to MetaCart
A formal specification of a Java Secure Processor is presented, which is mechanically checked for type consistency, well formedness and operational conservativity. The specification is executable and it is used to animate and study the behaviour of sample Java programs.
Operational Semantics of the Java Card Virtual Machine
, 2002
"... ... Java Card Virtual Machine Language. We use the instruction set and the program structures proposed in [1]. We define a smallstep relation between program con figurations, including rules for exception handling, arrays and subroutines. We also include the basic structures needed to model object ..."
Abstract

Cited by 13 (1 self)
 Add to MetaCart
... Java Card Virtual Machine Language. We use the instruction set and the program structures proposed in [1]. We define a smallstep relation between program con figurations, including rules for exception handling, arrays and subroutines. We also include the basic structures needed to model object ownership and the Java Card firewall.
An Executable Formal Java Virtual Machine Thread Model
, 2001
"... We discuss an axiomatic description of a simple abstract machine similar to the Java Virtual Machine (JVM). Our model supports classes, with fields and bytecoded methods, and a representative sampling of JVM bytecodes for basic operations for both data and control. The GETFIELD and PUTFIELD instru ..."
Abstract

Cited by 6 (0 self)
 Add to MetaCart
We discuss an axiomatic description of a simple abstract machine similar to the Java Virtual Machine (JVM). Our model supports classes, with fields and bytecoded methods, and a representative sampling of JVM bytecodes for basic operations for both data and control. The GETFIELD and PUTFIELD instructions accurately model inheritance, as does the INVOKEVIRTUAL instruction. Our model supports multiple threads, synchronized methods, and monitors. Our current model is inadequate or inaccurate
Formalising the Safety of Java, the Java Virtual Machine and Java Card
"... State Machine Semantics (ASM), Axiomatic Semantics (AS), Context Rewriting semantics (CR), Continuation or monad Semantics (CS), Denotational Semantics (DS), Natural Semantics (NS), Operational Semantics (OS), Structural Operational Semantics (SOS), or a semantic embedding in a higher odrder logic ( ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
State Machine Semantics (ASM), Axiomatic Semantics (AS), Context Rewriting semantics (CR), Continuation or monad Semantics (CS), Denotational Semantics (DS), Natural Semantics (NS), Operational Semantics (OS), Structural Operational Semantics (SOS), or a semantic embedding in a higher odrder logic (HOL).
A Denial of Service Attack on the Java Bytecode
, 2003
"... Java Bytecode Verification was so far mostly approached from a correctness perspective. Security vulnerabilities have been found repeatedly and were corrected shortly thereafter. However, correctness is not the only potential point of failure in the verifier idea. In this paper we construct Java cod ..."
Abstract
 Add to MetaCart
Java Bytecode Verification was so far mostly approached from a correctness perspective. Security vulnerabilities have been found repeatedly and were corrected shortly thereafter. However, correctness is not the only potential point of failure in the verifier idea. In this paper we construct Java code, which is correct, but requires an excessive amount of time to prove safety. In contrast to previous flaws in the bytecode verifier, the enabling property for this exploit lies in the verification algorithm itself and not in the implementation and is thus not easily fixable. We explain how this architectural weakness could be exploited for denialofservice attacks on JVMbased services and devices.
Partial Functions in ACL2
"... Like defun, defpun adds an axiom equating a call of a new function symbol to some term, usually involving recursive calls. Like defun, our macro preserves the consistency of the logic. It works by recognizing several special cases and dealing with each in a special way. The main challenge in using e ..."
Abstract
 Add to MetaCart
Like defun, defpun adds an axiom equating a call of a new function symbol to some term, usually involving recursive calls. Like defun, our macro preserves the consistency of the logic. It works by recognizing several special cases and dealing with each in a special way. The main challenge in using encapsulate to introduce a new function symbol is to generate a witness function satisfying the desired axiom. In some cases the user supplies hints as to how to establish consistency. Here are several examples of partially defined functions admitted under our macro. Each falls into a different special case. After these examples we will present a more thorough discussion of the issues and techniques. (defpun offset (n) (declare (xargs:witness fix)) (if (equal n 0) 0 (+ 1 (offset ( n 1))))) The event above adds the axiom that (offset n) is equal to (if (equal n 0) 0 (+ 1 (offset ( n 1)))). Observe that if you tried to add this axiom 2 with defun it would fail because no termination proof is possible. Indeed, what is the value of (offset3)? Here is a partial function that is uniquely defined on a specified domain. The "g " in:gdomain stands for "guarded " and insures that the equation is closed on the domain. We discuss this issue later.