ISA semantics for ARMv8-a, RISC-v, and CHERI-MIPS

Abstract

Architecture specifications notionally define the fundamental interface between hardware and software: the envelope of allowed behaviour for processor implementations, and the basic assumptions for software development and verification. But in practice, they are typically prose and pseudocode documents, not rigorous or executable artifacts, leaving software and verification on shaky ground. In this paper, we present rigorous semantic models for the sequential behaviour of large parts of the mainstream ARMv8-A, RISC-V, and MIPS architectures, and the research CHERI-MIPS architecture, that are complete enough to boot operating systems, variously Linux, FreeBSD, or seL4. Our ARMv8-A models are automatically translated from authoritative ARM-internal definitions, and (in one variant) tested against the ARM Architecture Validation Suite. We do this using a custom language for ISA semantics, Sail, with a lightweight dependent type system, that supports automatic generation of emulator code in C and OCaml, and automatic generation of proof-assistant definitions for Isabelle, HOL4, and (currently only for MIPS) Coq. We use the former for validation, and to assess specification coverage. To demonstrate the usability of the latter, we prove (in Isabelle) correctness of a purely functional characterisation of ARMv8-A address translation. We moreover integrate the RISC-V model into the RMEM tool for (user-mode) relaxed-memory concurrency exploration. We prove (on paper) the soundness of the core Sail type system. We thereby take a big step towards making the architectural abstraction actually well-defined, establishing foundations for verification and reasoning. CCS Concepts: • General and reference → Verification; • Theory of computation → Semantics and reasoning; • Computer systems organization → Architectures; • Software and its engineering → Assembly languages;

QED at Large: A Survey of Engineering of Formally Verified Software

“…Fox and Myreen (2010) developed formal specifications (semantics) of the ISA for ARMv7 in HOL4. Armstrong et al (2019) later used a domain-specific language to provide ISA specifications for Isabelle/HOL, HOL4, and Coq for the ARMv8, RISC-V, and CHERI-MIPS architectures. Morrisett et al (2012) modeled a subset of the x86 ISA in Coq, and used it to build a verified checker for a sandbox policy.…”

Promising-ARM/RISC-V: a simpler and faster operational concurrency model

“…Secondly, while the Coq model formalises the small imperative language, the executable model integrates definitions for user-mode ARMv8 and RISC-V instructions, meaning it needs logic for computing the views of loads and stores of the ISA definitions [13,22]. (Like Flat, our Sail model does not yet include ARM's weaker load acquire LDAPR introduced in ARMv8.3.…”

“…In contrast to Flat, this model executes an instruction in a single step and -except early writes -in order, and does not speculate branches. The exploration tool integrates models for large parts of the user-mode ARMv8 [22] and RISC-V [13] ISAs written in Sail [13,24] (the same as those used by Flat). This provides a significant advantage over the axiomatic models that do not include a substantial ISA model.…”

ARMv8-A System Semantics: Instruction Fetch in Relaxed Architectures

“…This is chiefly a problem of scale: modern industrial architectures such as Arm or x86 have large instruction sets, and each instruction involves many details, including its behaviour at different privilege levels, virtual-to-physical address translation, and so on -a single Arm instruction might involve hundreds of auxiliary functions. Recent work by Reid et al within Arm [40,41,42] transitioned their internal ISA description into a mechanised form, used both for documentation and testing, and with him we automatically translated this into publicly available Sail definitions and thence into theorem-prover definitions [11,10]. Other related work is in §7.…”

“…We make the operational model executable as a test oracle by integrating it into the RMEM tool and its web interface [17], introducing optimisations that make it possible to exhaustively execute the examples. We make the axiomatic model executable as a test oracle with a new tool that takes litmus tests and uses a Sail [11] definition of a fragment of the ARMv8-A ISA to generate SMT problems for the model. We then compare hardware and the two models for the handwritten tests (modulo two tests not supported by the axiomatic checker), compare hardware and the operational model on a suite of 1456 tests, automatically generated with an extension of the diy tool [3], and check the operational and axiomatic models against sets of previous non-ifetch tests.…”