ArticlePublisher preview available

An Isabelle/HOL Formalisation of the SPARC Instruction Set Architecture and the TSO Memory Model

DOI:10.1007/s10817-020-09579-4
Authors:
Zhe Hou at Griffith University
Zhe Hou
David Sanán at Nanyang Technological University
David Sanán
Alwen Tiu
Alwen Tiu
Alwen Tiu
  • This person is not on ResearchGate, or hasn't claimed this research yet.
Yang Liu at Nanyang Technological University
Yang Liu
Show all 6 authorsHide
Read publisher preview
Download citation
To read the full-text of this research, you can request a copy directly from the authors.

Abstract and Figures

The SPARC instruction set architecture (ISA) has been used in various processors in workstations, embedded systems, and in mission-critical industries such as aviation and space engineering. Hence, it is important to provide formal frameworks that facilitate the verification of hardware and software that run on or interface with these processors. In this work, we give the first formal model for multi-core SPARC ISA and Total Store Ordering (TSO) memory model in Isabelle/HOL. We present two levels of modelling for the ISA: The low-level ISA model, which is executable, covers many features specific to SPARC processors, such as delayed-write for control registers, windowed general registers, and more complex memory access. We have tested our model extensively against a LEON3 simulation board, the test covers both single-step executions and sequential execution of programs. We also prove some important properties for our formal model, including a non-interference property for the LEON3 processor. The high-level ISA model is an abstraction of the low-level model and it provides an interface for memory operations in multi-core processors. On top of the high-level ISA model, we formalise two TSO memory models: one is an adaptation of the axiomatic SPARC TSO model (Sindhu et al. in Formal specification of memory models, Springer, Boston, 1992; SPARC in The SPARC architecture manual version 8, 1992. http://gaisler.com/doc/sparcv8.pdf), the other is a new operational TSO model which is suitable for verifying execution results. We prove that the operational model is sound and complete with respect to the axiomatic model. Finally, we give verification examples with two case studies drawn from the SPARCv9 manual.
Figures - available from: Journal of Automated Reasoning
This content is subject to copyright. Terms and conditions apply.
  • A preview of this full-text is provided by Springer Nature.
  • Learn more
Preview content only
Content available from Journal of Automated Reasoning
This content is subject to copyright. Terms and conditions apply.
Journal of Automated Reasoning (2021) 65:569–598
https://doi.org/10.1007/s10817-020-09579-4
An Isabelle/HOL Formalisation of the SPARC Instruction Set
Architecture and the TSO Memory Model
Zhé Hóu1·David Sanan2·Alwen Tiu3·Yang Liu2·Koh Chuen Hoa4·
Jin Song Dong5
Received: 12 September 2019 / Accepted: 7 August 2020 / Published online: 14 August 2020
© Springer Nature B.V. 2020
Abstract
The SPARC instruction set architecture (ISA) has been used in various processors in work-
stations, embedded systems, and in mission-critical industries such as aviation and space
engineering. Hence, it is important to provide formal frameworks that facilitate the verifica-
tion of hardware and software that run on or interface with these processors. In this work,
we give the first formal model for multi-core SPARC ISA and Total Store Ordering (TSO)
memory model in Isabelle/HOL. We present two levels of modelling for the ISA: The low-
level ISA model, which is executable, covers many features specific to SPARC processors,
such as delayed-write for control registers, windowed general registers, and more complex
memory access. We have tested our model extensively against a LEON3 simulation board,
the test covers both single-step executions and sequential execution of programs. We also
prove some important properties for our formal model, including a non-interference property
for the LEON3 processor. The high-level ISA model is an abstraction of the low-level model
and it provides an interface for memory operations in multi-core processors. On top of the
high-level ISA model, we formalise two TSO memory models: one is an adaptation of the
axiomatic SPARC TSO model (Sindhu et al. in Formal specification of memory models,
Springer, Boston, 1992; SPARC in The SPARC architecture manual version 8, 1992. http://
gaisler.com/doc/sparcv8.pdf), the other is a new operational TSO model which is suitable
for verifying execution results. We prove that the operational model is sound and complete
with respect to the axiomatic model. Finally, we give verification examples with two case
studies drawn from the SPARCv9 manual.
Keywords Instruction set architecture ·Form verification ·Isabelle/HOL ·Weak memory
model ·TSO
1 Introduction
Formal models of instruction set architectures (ISAs) not only provide a rigorous under-
standing of the semantics for instructions, but also are useful in verifying low-level programs
BZhé Hóu
z.hou@griffith.edu.au
Extended author information available on the last page of the article
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
... The common presentation of Total Store Order (TSO) memory model is operational [18]. In addition to the traditional interleaving semantics, each hardware thread under TSO has a write buffer and propagates writes to the main memory nondeterministically. Hóu et al. [19] presented axiomatic TSO model and operational TSO model on the top of high-level ISA model and low-level ISA model. Using axiomatic memory model definitions, Lahav et al. [17] listed several laws that WMMs such as TSO or other non-multi-copy-atomic memory models should follow respectively. ...
Modeling and Verifying PSO Memory Model Using CSP
Article
Full-text available
Modern processors deploy a variety of weak memory models for efficiency reasons. Total Store Order (TSO) is a widely used weak memory model which omits store-load constraint by allowing each core to employ a write buffer. Partial Store Order (PSO) is similar to TSO, but in consideration of higher performance, it does not guarantee that writes to different locations propagate to the shared memory following the program order. For understanding the reordering appearing in PSO precisely, we analyze this memory model by utilizing formal methods. In this paper, we apply Communicating Sequential Processes (CSP) to model PSO. By feeding the constructed model into the model checker Process Analysis Toolkit (PAT), we verify four properties. The requirements of TSO are more stringent than PSO, and then PSO must preserve write-read reordering and read-after-write elimination defined by TSO. The programs containing store-store fences between every two writes have the same outcomes under TSO and PSO, which is called outcomes consistency. Last but not the least, PSO should satisfy write-write reordering which indicates that two writes by the same thread may be reordered if they target different locations.
View
... The project adopts a multi-layer verification approach where we formalise each layer separately and use a refinement-based approach to show that properties proved at the top level are preserved at the lower levels. This work closely connects with the other components of the project such as the formal modelling and verification of verilog [8] and the SPARCv8 instruction set architecture for the LEON3 processor [9], [10], a verification framework for concurrent C-like programs [11], and automated reasoning techniques for separation logic [12]- [14]. For easy integration, these related sub-projects partly determine our software choices such as Isabelle/HOL and hardware choices such as LEON3 and VHDL. ...
An Executable Formal Model of the VHDL in Isabelle/HOL
Preprint
Full-text available
  • Feb 2022
In the hardware design process, hardware components are usually described in a hardware description language. Most of the hardware description languages, such as Verilog and VHDL, do not have mathematical foundation and hence are not fit for formal reasoning about the design. To enable formal reasoning in one of the most commonly used description language VHDL, we define a formal model of the VHDL language in Isabelle/HOL. Our model targets the functional part of VHDL designs used in industry, specifically the design of the LEON3 processor's integer unit. We cover a wide range of features in the VHDL language that are usually not modelled in the literature and define a novel operational semantics for it. Furthermore, our model can be exported to OCaml code for execution, turning the formal model into a VHDL simulator. We have tested our simulator against simple designs used in the literature, as well as the div32 module in the LEON3 design. The Isabelle/HOL code is publicly available: https://zhehou.github.io/apps/VHDLModel.zip
View
... The other major challenge is the limited processing capacity on board of the satellite, specifically as power is mainly provided from a solar battery. Although modern satellites employ faster CPUs, many models are still significantly slower than consumer desktops [1], [2]. Running formal verification directly on satellites may take up too much computational resource that could have been allocated to communication and other tasks. ...
A Digital Twin Runtime Verification Framework for Protecting Satellites Systems from Cyber Attacks
Conference Paper
Full-text available
  • Mar 2022
This paper presents the conceptualisation of a framework that combines digital twins with runtime verification and applies the techniques in the context of security monitoring and verification for satellites. We focus on special considerations needed for space missions and satellites, and we discuss how digital twins in such applications can be developed and how the states of the twins should be synchronised. In particular, we present state synchronisation methods to ensure secure and efficient long-distance communication between the satellite and its digital twin on the ground. Building on top of this, we develop a runtime verification engine for the digital twin that can verify properties in multiple temporal logic languages. We end the paper with our proposal to develop a fully verified satellite digital twin system as future work.
View
View
Trace Semantics and Algebraic Laws for Total Store Order Memory Model
Article
  • Dec 2021
Modern multiprocessors deploy a variety of weak memory models (WMMs). Total Store Order (TSO) is a widely-used weak memory model in SPARC implementations and x86 architecture. It omits the store-load constraint by allowing each core to employ a write buffer. In this paper, we apply Unifying Theories of Programming (abbreviated as UTP) in investigating the trace semantics for TSO, acting in the denotational semantics style. A trace is expressed as a sequence of snapshots, which records the changes in registers, write buffers and the shared memory. All the valid execution results containing reorderings can be described after kicking out those that do not satisfy program order and modification order. This paper also presents a set of algebraic laws for TSO. We study the concept of head normal form, and every program can be expressed in the head normal form of the guarded choice which is able to model the execution of a program with reorderings. Then the linearizability of the TSO model is supported. Furthermore, we consider the linking between trace semantics and algebraic semantics. The linking is achieved through deriving trace semantics from algebraic semantics, and the derivation strategy under the TSO model is provided.
View
SafeOSL: Ensuring memory safety of C via ownership‐based intermediate language
Article
  • Dec 2021
The unsafe features of C make it a big challenge to ensure memory safety of C programs, and often lead to memory errors that can result in vulnerabilities. Various formal verification techniques for ensuring memory safety of C have been proposed. However, most of them either have a high overhead, such as state explosion problem in model checking, or have false positives, such as abstract interpretation. In this article, by innovatively borrowing ownership system from Rust, we propose a novel and sound static memory safety analysis approach, named SafeOSL. Its basic idea is an ownership-based intermediate language, called ownership system language (OSL), which captures the features of the ownership system in Rust. Ownership system specifies the relations among variables and memory locations, and maintains invariants that can ensure memory safety. The semantics of OSL is formalized in K-framework, which is a rewriting-logic based tool. C programs to be checked are first transformed into OSL programs and then detected by OSL semantics. Experimental results have demonstrated that SafeOSL is effective in detecting memory errors of C. Moreover, the translations and experiments indicate that the intermediate language OSL could be reused by other programming languages to detect memory errors.
View
An Executable Formalisation of the SPARCv8 Instruction Set Architecture: A Case Study for the LEON3 Processor
Conference Paper
Full-text available
  • Nov 2016
The SPARCv8 instruction set architecture (ISA) has been used in various processors for workstations, embedded systems, and space missions. However, there are no publicly available formal models for the SPARCv8 ISA. In this work, we give the first formal model for the integer unit of SPARCv8 ISA in Isabelle/HOL. We capture the operational semantics of the instructions using monadic definitions. Our model is a detailed model, which covers many features specific to SPARC processors, such as delayed-write for control registers, windowed general registers, and more complex memory access. Our model is also general, as we retain an abstract layer of the model which allows it to be instantiated to support all SPARCv8 compliant processors. We extract executable code from our formalisation, giving us the first systematically verified executable semantics for the SPARCv8 ISA. We have tested our model extensively against a LEON3 simulation board, covering both single-step executions and sequential execution of programs. We prove some important properties for our formal model, including a non-interference property for the LEON3 processor.
View
Lem
Article
Full-text available
Recent years have seen remarkable successes in rigorous engineering: using mathematically rigorous semantic models (not just idealised calculi) of real-world processors, programming languages, protocols, and security mechanisms, for testing, proof, analysis, and design. Building these models is challenging, requiring experimentation, dialogue with vendors or standards bodies, and validation; their scale adds engineering issues akin to those of programming to the task of writing clear and usable mathematics. But language and tool support for specification is lacking. Proof assistants can be used but bring their own difficulties, and a model produced in one, perhaps requiring many person-years effort and maintained over an extended period, cannot be used by those familiar with another. We introduce Lem, a language for engineering reusable large-scale semantic models. The Lem design takes inspiration both from functional programming languages and from proof assistants, and Lem definitions are translatable into OCaml for testing, Coq, HOL4, and Isabelle/HOL for proof, and LaTeX and HTML for presentation. This requires a delicate balance of expressiveness, careful library design, and implementation of transformations - akin to compilation, but subject to the constraint of producing usable and human-readable code for each target. Lem's effectiveness is demonstrated by its use in practice.
View
An integrated concurrency and core-ISA architectural envelope definition, and test oracle, for IBM POWER multiprocessors
Conference Paper
Full-text available
  • Dec 2015
Weakly consistent multiprocessors such as ARM and IBM POWER have been with us for decades, but their subtle programmer-visible concurrency behaviour remains challenging, both to implement and to use; the traditional architecture documentation, with its mix of prose and pseudocode, leaves much unclear. In this paper we show how a precise architectural envelope model for such architectures can be defined, taking IBM POWER as our example. Our model specifies, for an arbitrary test program, the set of all its allowable executions, not just those of some particular implementation. The model integrates an operational concurrency model with an ISA model for the fixed-point non-vector user-mode instruction set (largely automatically derived from the vendor pseudocode, and expressed in a new ISA description language). The key question is the interface between these two: allowing all the required concurrency behaviour, without overcommitting to some particular microarchitectural implementation, requires a novel abstract structure. Our model is expressed in a mathematically rigorous language that can be automatically translated to an executable test-oracle tool; this lets one either interactively explore or exhaustively compute the set of all allowed behaviours of intricate test cases, to provide a reference for hardware and software development.
View
View
Simplifying ARM concurrency: multicopy-atomic axiomatic and operational models for ARMv8
Article
  • Dec 2017
ARM has a relaxed memory model, previously specified in informal prose for ARMv7 and ARMv8. Over time, and partly due to work building formal semantics for ARM concurrency, it has become clear that some of the complexity of the model is not justified by the potential benefits. In particular, the model was originally non-multicopy-atomic: writes could become visible to some other threads before becoming visible to all — but this has not been exploited in production implementations, the corresponding potential hardware optimisations are thought to have insufficient benefits in the ARM context, and it gives rise to subtle complications when combined with other ARMv8 features. The ARMv8 architecture has therefore been revised: it now has a multicopy-atomic model. It has also been simplified in other respects, including more straightforward notions of dependency, and the architecture now includes a formal concurrency model. In this paper we detail these changes and discuss their motivation. We define two formal concurrency models: an operational one, simplifying the Flowing model of Flur et al., and the axiomatic model of the revised ARMv8 specification. The models were developed by an academic group and by ARM staff, respectively, and this extended collaboration partly motivated the above changes. We prove the equivalence of the two models. The operational model is integrated into an executable exploration tool with new web interface, demonstrated by exhaustively checking the possible behaviours of a loop-unrolled version of a Linux kernel lock implementation, a previously known bug due to unprevented speculation, and a fixed version.
View
A Calculus for Relaxed Memory
Conference Paper
We propose a new approach to programming multi-core, relaxed-memory architectures in imperative, portable programming languages. Our memory model is based on explicit, programmer-specified requirements for order of execution and the visibility of writes. The compiler then realizes those requirements in the most efficient manner it can. This is in contrast to existing memory models, which---if they allow programmer control over synchronization at all---are based on inferring the execution and visibility consequences of synchronization operations or annotations in the code. We formalize our memory model in a core calculus called RMC\@. Outside of the programmer's specified requirements, RMC is designed to be strictly more relaxed than existing architectures. It employs an aggressively nondeterministic semantics for expressions, in which actions can be executed in nearly any order, and a store semantics that generalizes Sarkar et al.'s and Alglave et al.'s models of the Power architecture. We establish several results for RMC, including sequential consistency for two programming disciplines, and an appropriate notion of type safety. All our results are formalized in Coq.
View
Machine Assisted Proof of ARMv7 Instruction Level Isolation Properties
Conference Paper
  • Dec 2013
In this paper, we formally verify security properties of the ARMv7 Instruction Set Architecture (ISA) for user mode executions. To obtain guarantees that arbitrary (and unknown) user processes are able to run isolated from privileged software and other user processes, instruction level noninterference and integrity properties are provided, along with proofs that transitions to privileged modes can only occur in a controlled manner. This work establishes a main requirement for operating system and hypervisor verification, as demonstrated for the PROSPER separation kernel. The proof is performed in the HOL4 theorem prover, taking the Cambridge model of ARM as basis. To this end, a proof tool has been developed, which assists the verification of relational state predicates semi-automatically.
View
VERIFYING CORRECT MICROARCHITECTURAL ENFORCEMENT OF MEMORY CONSISTENCY MODELS
Article
MEMORY CONSISTENCY MODELS DEFINE THE RULES AND GUARANTEES ABOUT THE ORDERING AND VISIBILITY OF MEMORY REFERENCES ON MULTITHREADED CPUS AND SYSTEMS ON CHIP. PIPECHECK OFFERS A METHODOLOGY AND AUTOMATED TOOL FOR VERIFYING THAT A PARTICULAR MICROARCHITECTURE CORRECTLY IMPLEMENTS THE CONSISTENCY MODEL REQUIRED BY ITS ARCHITECTURAL SPECIFICATION.
View
Modelling the ARMv8 Architecture, Operationally: Concurrency and ISA
Conference Paper
In this paper we develop semantics for key aspects of the ARMv8 multiprocessor architecture: the concurrency model and much of the 64-bit application-level instruction set (ISA). Our goal is to clarify what the range of architecturally allowable behaviour is, and thereby to support future work on formal verification, analysis, and testing of concurrent ARM software and hardware. Establishing such models with high confidence is intrinsically difficult: it involves capturing the vendor’s architectural intent, aspects of which (especially for concurrency) have not previously been precisely defined. We therefore first develop a concurrency model with a microarchitectural flavour, abstracting from many hardware implementation concerns but still close to hardware-designer intuition. This means it can be discussed in detail with ARM architects. We then develop a more abstract model, better suited for use as an architectural specification, which we prove sound w.r.t.~the first. The instruction semantics involves further difficulties, handling the mass of detail and the subtle intensional information required to interface to the concurrency model. We have a novel ISA description language, with a lightweight dependent type system, letting us do both with a rather direct represention of the ARM reference manual instruction descriptions. We build a tool from the combined semantics that lets one explore, either interactively or exhaustively, the full range of architecturally allowed behaviour, for litmus tests and (small) ELF executables. We prove correctness of some optimisations needed for tool performance. We validate the models by discussion with ARM staff, and by comparison against ARM hardware behaviour, for ISA single- instruction tests and concurrent litmus tests.
View
Improved Tool Support for Machine-Code Decompilation in HOL4
Conference Paper
  • Aug 2015
The HOL4 interactive theorem prover provides a sound logical environment for reasoning about machine-code programs. The rigour of HOL’s LCF-style kernel naturally guarantees very high levels of assurance, but it does present challenges when it comes implementing efficient proof tools. This paper presents improvements that have been made to our methodology for soundly decompiling machine-code programs to functions expressed in HOL logic. These advancements have been facilitated by the development of a domain specific language, called L3, for the specification of Instruction Set Architectures (ISAs). As a result of these improvements, decompilation is faster (on average by one to two orders of magnitude), the instruction set specifications are easier to write, and the proof tools are easier to maintain.
View