A Trustworthy Monadic Formalization of the ARMv7 Instruction Set Architecture Anthony Fox and Magnus O. Myreen Computer Laboratory, University of Cambridge, UK Abstract. This paper presents a new HOL4 formalization of the cur- rent ARM instruction set architecture, ARMv7. This is a modern RISC architecture with many advanced features. The formalization is detailed and extensive. Considerable tool support has been developed, with the goal of making the model accessible and easy to work with. The model and supporting tools are publicly available { we wish to encourage others to make use of this resource. This paper explains our monadic specifica- tion approach and gives some details of the endeavours that have been made to ensure that the sizeable model is valid and trustworthy. A novel and efficient testing approach has been developed, based on automated forward proof and communication with ARM development boards. 1 Introduction Instruction set architectures (ISAs) provide a precise interface between hard- ware (microprocessors) and software (high-level code). Formal models of instruc- tion sets are pivotal when verifying computer micro-architectures and compilers. There are also areas where it is appropriate to reason directly about low-level machine code, e.g. in verifying operating systems, embedded code and device drivers. Detailed architecture models have also been used in formalizing multi- processor memory models, see [15]. In the past, academic work has frequently examined the pedagogical DLX architecture, see [6]. When compared to commercial architectures, DLX is rela- tively uncomplicated { being a simplified version of the MIPS RISC architecture. Consequently, it is rarely cumbersome to work with the entire DLX instruction set. More recently there has been a move to modelling, and working with, com- mercial instruction sets (possibly in a reduced form). This has been motivated by a desire to carry out demonstrably realistic case studies, showing that various techniques scale and are not purely \academic" in nature. Common commercial architectures include: IA-32, x86-64, PowerPC, Sparc and ARM. The ARM architecture is ubiquitous in low-powered (mobile and embedded) computing devices { the latest version of the architecture, dubbed ARMv7, is implemented by, for example, the Cortex-A8 processor. There are many challenges when working with full-blown ISAs, these in- clude: (i) official reference manuals are large, stretching to many hundreds of pages { one can easily overlook subtle details or become bogged down with \un- interesting" background information; (ii) official descriptions are semi-formal (ambiguous); (iii) many details are implementation dependent or unpredictable; (iv) architectures frequently have multiple generations, versions and optional ex- tensions; and (v) large formalizations can stretch the capabilities of interactive theorem provers. Most importantly: how can one be sure that the formalization does not contain bugs? The scale and complexity is such that it is not possi- ble to eradicate all errors by simply eyeballing the specification or examining a few instructions. This paper discusses our experiences with constructing and validating a complete model of the ARMv7 architecture using the HOL4 proof system [16]. 2 Approach Some key aspects of the work presented here are: { The ARM instruction set architecture has been modelled in HOL using a monadic style. This approach has a number of advantages, which are dis- cussed in Section 3. { The model is extensive and detailed { it covers all architecture versions cur- rently supported by ARM, including full support for Thumb-2 instructions.1 { A collection of tools have been built around the model, making it accessible and easy to work with. This includes an assembler and disassembler, both of which are implemented in Standard ML. There is also a tool for auto- matically extracting the semantics of a single instruction from the model: this is implemented through evaluation (forward proof) and is discussed in Section 4. { A distinction is made between entities that are defined or derived inside of the HOL logic and those that reside outside { this is illustrated in Figure 1. It is important that everything defined inside of the logic is valid. On the other hand, although it is advantageous that the other tools (e.g. the parser and encoder) are bug free, these are not fundamentally relied upon in formal verification work. { The model operates at the machine code level, as opposed to a more abstract assembly code level. In particular, the model does not provide assembly level \pseudo instructions" and instruction decoding is explicitly modelled inside the logic. This means that the the model can be directly validated by comparing results against the behaviour of hardware employing ARM processors { this is discussed in Section 5. Through the use of extensive validation, trust in the model is progressively es- tablished. An efficient testing framework has been developed, which is based on a HOL session communicating with an ARM development board (via a serial port). This set-up is required because most PCs are based on x86 processors and cannot natively run ARM code. The results from this testing are discussed in Section 5.3. Due to space constraints, precise details of the ARM architecture are not provided here, readers are instead referred to [4] and [11]. 1 It does not cover the ARMv7-M profile (which has a slightly different programmer's model) or the ThumbEE, Jazelle, VFP and Advanced SIMD extensions. Outside HOL Logic Assembly Code (ML string or quotation) parse disassemble Machine Code Abstract Syntax encode (Hexadecimal string) (HOL terms) validation Next Step Machine Code Abstract Syntax decode next state Theorem (HOL n-bit word) (HOL instruction type) (HOL theorem) Evaluation Inside HOL Logic code verification Fig. 1. Overall structure of the formalization. 3 Monadic Specification The HOL4 system provides built-in support for defining recursive, total functions (see [17]). Consequently, formal specifications can be written in a functional programming style using syntax roughly similar to that of ML. For example, in the HOL4 model of the ARMv4 architecture (see [3]), a typical definition is of the following form: f(v1; : : : ; vm) = let x1 = g1(::: ) in ::: let xn = gn(::: ) in (w1; : : : ; wm) If f defines the semantics of a machine code instruction then the vector v would represent the components of the programmer's model state space (for example, machine registers) and w specifies the next state. The variables xi are intermedi- ate computations; typically the result of accessing, updating and manipulating state components. There are a few problems with this particular style of speci- fication: { Explicitly naming state component (splitting the state into a vector) can make it harder to make global changes to sizeable specifications, e.g. adding, removing or changing the type of state components. { The semantics is rigidly fixed to that of a state transformer. In particular, it is not possible to reason about the order of intermediate computations, observing whether or not they were performed sequentially or in parallel. { For those more familiar with imperative code, the specification is not espe- cially readable. { It is not obvious how to handle memory I/O, non-determinism or \error states". All of these factors motivate the use of a monadic programming style (see [18]), where computations themselves are represented with an abstract data type. Let M represent a monad type constructor. The two fundamental monad operations are return and bind, represented by: return : α ! α M and = : α M ! (α ! β M) ! β M respectively. The return operation gives a value to a computation. The bind operation composes computations: it takes the result of one computation and passes it on to another. The type variables α and β represent the types for working values in a computation: these roughly correspond with the variables and arguments of procedures and functions in an imperative language. The monad type constructor M, and associated primitive operations, can be defined in any number of ways, implementing various underlying computational models { this can loosely correspond with defining a semantics (and run-time environment) for a given programming language. In addition to the two primitive monad operations, our specifications also makes use of a parallel operation: : α M ! β M ! (α × β) M : 9 This performs two operations, but without imposing an order of evaluation. 3.1 Sequential Monad It is possible to define monads in HOL without considering concrete implemen- tations: one could, for example, provide an axiomatic formalization. However, there are advantages to being able to actually carry out computations with the model (see Section 4). This section presents a sequential monad { this has formed the primary basis for working with the ARM specification. The monad provides a simple operational semantics in a shallow embedding style { this is suited to evaluation and code verification with a Hoare style logic. The overall HOL specification is split into two parts: the monad specification and the instruction set specification. This means that the instruction set specification part can be interpreted by any other monad with the same interface. The type constructor for the sequential monad is as follows: α Mseq ≡ state ! (α × state) MaybeError where state is the programmer's model state space and β MaybeError = Okay of β j Error of string : This is essentially a state-transformer monad with error states. The monad type can be viewed as a partial map, representing a state transition with a return value. When the map is “undefined”, the result is a tagged string { this can be used to identify where an error occurred. The basic monad operations are defined as follows: return (v) = λs. Okay (v; s) ; " # case f(s) of Error e ! Error e (f = g) = λs. j Okay (v; s0) ! g(v)(s0) and (f g) = (f = (λv1: g = (λv2: return (v1; v2)))) : 9 Note that errors are terminal (no further next state computation is performed) and the parallel operation simply performs computations in a left to right order.