Fig 1
Sail ISA semantics and (in yellow) the generated prover and emulator versions. The grey parts are previous concurrency and ISA models, user-mode only and not yet fully integrated into current Sail
Source publication
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...
Contexts in source publication
Context 1
... it did not provide generation of prover definitions or emulators. In this paper, we extend Sail with the automatic translations depicted in Fig 1: from the ARM-internal ASL language into Sail, from Sail to C and OCaml emulator code (ğ5), and from Sail to Isabelle/HOL, HOL4, and Coq theorem-prover definitions (ğ4). This common infrastructure for all our architecture models saves much duplication of effort. ...
Context 2
... E : {|5, 8, 11|} = if 'N == 16 then 5 else if 'N == 32 then 8 else 11; let F = 'N -(E + 1); let exp = 0b1 @ Zeros(E -1); let frac = 0b1 @ Zeros (F -1); sign @ exp @ frac } Fig. 8. FPThree function translated into Sail harder task than just generating syntactically-correct Sail. ASL's typesystem is a compromise between expressivity and the ability to detect errors: like Sail, it provides dependent types for bitvector sizes and statically checks every function call but, unlike Sail, uses of bitvector indexing are not statically checked. ...
Context 3
... of imperative, effectful Sail code into monadic code for the generation of prover definitions is largely standard, rewriting into a sequence of monadic and let-bindings similar to A-normal form [Flanagan et al. 1993], but where the criterion is that arguments to functions must be pure. For example, the effectful first operand of add _ vec in Fig. 10 has been pulled out into a monadic bind. Local mutable variable updates are translated to pure let-bindings, where local blocks that update variables, e.g. loop bodies and the branches of if-expressions, are rewritten to return the updated values so that they can be picked up by the surrounding context, while respecting their scoping. ...
Context 4
... than would be possible with Lem's rudimentary Coq output support. The main difference in our Coq translation compared to our other backends is that the type-level sizes and constraints are fully retained in the generated Coq definitions. In particular, Sail's existential types are translated to dependent pairs in Coq. This can be seen in Fig. 11, the translation of Fig. 8, where a dependent pair is built for E to show that it is in the set {5, 8, 11}. However, it would be extremely challenging to reuse proofs about the constraints from the SMT solver used during Sail type checking, so instead we use a Coq typeclass wrapper to trigger a constraint solving tactic. In Fig. 11 ...
Context 5
... can be seen in Fig. 11, the translation of Fig. 8, where a dependent pair is built for E to show that it is in the set {5, 8, 11}. However, it would be extremely challenging to reuse proofs about the constraints from the SMT solver used during Sail type checking, so instead we use a Coq typeclass wrapper to trigger a constraint solving tactic. In Fig. 11 this is done by the build _ ex function. The core of the tactic is Coq's implementation of the Omega Presburger arithmetic decision procedure [Pugh 1991], with additional preprocessing to transform information from the context into a useful form and to evaluate constant powers of 2. The solver can also be extended by adding facts to a ...
Context 6
... Sail that we judge to have an influence on the form of the SMT queries generated. These are a selection of value constructor and elimination forms, immutable and mutable variable binding statements, and imperative language statements. An example of a Sail feature that we do not include in MiniSail are records as these can be emulated using pairs. Fig. 12 presents MiniSail's grammar and a table of judgements, and Fig. 13 presents a selection of the typing rules. The grammar in Fig. 12 defines a language in a slight variant of A-normal form. Programs are defined from expressions (which include arithmetic, variables, and function applications), and statements (which include let-binding, ...
Context 7
... generated. These are a selection of value constructor and elimination forms, immutable and mutable variable binding statements, and imperative language statements. An example of a Sail feature that we do not include in MiniSail are records as these can be emulated using pairs. Fig. 12 presents MiniSail's grammar and a table of judgements, and Fig. 13 presents a selection of the typing rules. The grammar in Fig. 12 defines a language in a slight variant of A-normal form. Programs are defined from expressions (which include arithmetic, variables, and function applications), and statements (which include let-binding, conditionals, and the assignment and declaration of mutable ...
Context 8
... forms, immutable and mutable variable binding statements, and imperative language statements. An example of a Sail feature that we do not include in MiniSail are records as these can be emulated using pairs. Fig. 12 presents MiniSail's grammar and a table of judgements, and Fig. 13 presents a selection of the typing rules. The grammar in Fig. 12 defines a language in a slight variant of A-normal form. Programs are defined from expressions (which include arithmetic, variables, and function applications), and statements (which include let-binding, conditionals, and the assignment and declaration of mutable variables). Note that we distinguish bindings of immutable variables let ...
Context 9
... key technical idea ensuring decidability is as follows: whenever we have an expression in the SMT fragment, we record an exact constraint. Otherwise, we merely propagate any SMT constraints by attaching them to variables, using A-normal form to ensure that there is always a name to attach a constraint to. Rules 1-5 in Fig. 13 give typing rules for expressions. Since each of these terms is in the SMT fragment, we can generate an exact equality constraint for them. However, rules 6 and 7 (for function applications and mutable variables) are for terms not in the SMT fragment, and so we use the type as an approximation, with mutable variables just looking up ...
Citations
... Consequently, integrating generalpurpose cores or FPGA units in memory substrates presents significant challenges. Further, programming such systems requires complex instructions that are generally not a part of memory ISAs [184]. ...
Resistive Random-Access Memory (RRAM) is well-suited to accelerate neural network (NN) workloads as RRAM-based Processing-in-Memory (PIM) architectures natively support highly-parallel multiply-accumulate (MAC) operations that form the backbone of most NN workloads. Unfortunately, NN workloads such as transformers require support for non-MAC operations (e.g., softmax) that RRAM cannot provide natively. Consequently, state-of-the-art works either integrate additional digital logic circuits to support the non-MAC operations or offload the non-MAC operations to CPU/GPU, resulting in significant performance and energy efficiency overheads due to data movement. In this work, we propose NEON, a novel compiler optimization to enable the end-to-end execution of the NN workload in RRAM. The key idea of NEON is to transform each non-MAC operation into a lightweight yet highly-accurate neural network. Utilizing neural networks to approximate the non-MAC operations provides two advantages: 1) We can exploit the key strength of RRAM, i.e., highly-parallel MAC operation, to flexibly and efficiently execute non-MAC operations in memory. 2) We can simplify RRAM's microarchitecture by eliminating the additional digital logic circuits while reducing the data movement overheads. Acceleration of the non-MAC operations in memory enables NEON to achieve a 2.28x speedup compared to an idealized digital logic-based RRAM. We analyze the trade-offs associated with the transformation and demonstrate feasible use cases for NEON across different substrates.
... First, even just the sequential definition of Armv8-A address translation, with the page-table walk and its options, is remarkably intricate, defined in thousands of lines of Arm's ASL instruction description language. Manually reimplementing a simplified version would be error-prone and incomplete, so we instead build on our Isla tool [15], which integrates the full 123,000 line Armv8-A ISA semantics (as defined by Arm in ASL and automatically translated into Sail [14]), with SMT-based tooling to evaluate tests w.r.t. axiomatic concurrency models. ...
... Several works give non-relaxed-memory semantics for Arm or x86 address translation, more or less simplified and with or without TLBs: Bauereiss [14], Goel et al. [34,35], Syeda and Klein [58,60,59,61], Degenbaev [29] (used for verification of a hypervisor shadow pagetable implementation [42,28,11,10]), Barthe ...
Virtual memory is an essential mechanism for enforcing security boundaries, but its relaxed-memory concurrency semantics has not previously been investigated in detail. The concurrent systems code managing virtual memory has been left on an entirely informal basis, and OS and hypervisor verification has had to make major simplifying assumptions. We explore the design space for relaxed virtual memory semantics in the Armv8-A architecture, to support future system-software verification. We identify many design questions, in discussion with Arm; develop a test suite, including use cases from the pKVM production hypervisor under development by Google; delimit the design space with axiomatic-style concurrency models; prove that under simple stable configurations our architectural model collapses to previous "user" models; develop tooling to compute allowed behaviours in the model integrated with the full Armv8-A ISA semantics; and develop a hardware test harness. This lays out some of the main issues in relaxed virtual memory bringing these security-critical systems phenomena into the domain of programming-language semantics and verification with foundational architecture semantics. This document is an extended version of a paper in ESOP 2022, with additional explanation and examples in the main body, and appendices detailing our litmus tests, models, proofs, and test results.
... In our opinion, the primary focus for increasing trust in CompCert (and removing possible further bugs) should be a validation mechanism of its assembly and ABI specification with respect to the actual execution platform. For example, SAIL provides a formal ISA semantics for ARMv8 that has been tested against the ARM Architecture Validation Suite [1]. However, CompCert cannot be directly plugged on SAIL, because of its more abstract view of the ISA. ...
CompCert is the first realistic formally verified compiler: it provides a machine-checked mathematical proof that the code it generates matches the source code. Yet, there could be loopholes in this approach. We comprehensively analyze aspects of CompCert where errors could lead to incorrect code being generated. Possible issues range from the modeling of the source and the target languages to some techniques used to call external algorithms from within the compiler.
... Relational properties received considerable attention after the discovery of the Meltdown [166] and Spectre [149] attacks, which revealed that most modern processors were amenable to sophisticated attacks that exploit the e ects of speculative executions at the microarchitectural level. As a result, various methods and tools were proposed to detect and prevent such attacks (e.g., [226,11,68]). The core problem of Meltdown and Spectre is that speculatively loaded data can be leaked to an attacker through cache timing side channels. ...
... We declare all constants and elds that appear in the speci cation as well as a variable storing the owner's address (l. [8][9][10][11][12][13]. Constants are labeled immutable and can either be assigned a prede ned value provided by the developer (l. ...
... There is also abundant work on the development of formal ISA specifications (e.g., [2,4,8,9]). However, almost all of them focus on the problem of rigorously defining the semantics of ISAs (such as their sequential behaviors, concurrency models and interrupt behaviors). ...
Verification of instruction encoders and decoders is essential for formalizing manipulation of machine code. The existing approaches cannot guarantee the critical consistency property, i.e., that an encoder and its corresponding decoder are mutual inverses of each other. We observe that consistent encoder-decoder pairs can be automatically derived from bijections inherently embedded in instruction formats. Based on this observation, we develop a framework for writing specifications that capture these bijections, for automatically generating encoders and decoders from these specifications, and for formally validating the consistency and soundness of the generated encoders and decoders by synthesizing proofs in Coq and discharging verification conditions using SMT solvers. We apply this framework to a subset of X86-32 instructions to illustrate its effectiveness in these regards. We also demonstrate that the generated encoders and decoders have reasonable performance.
... ISA specifies the behavior of the running machine code without relying on specific machine implementations, thereby providing program compatibility between different implementations of the same architecture. The architecture specification conceptually defines the basic interface between hardware and software, the behaviors allowed for processor implementation, and the basic assumptions for software development and verification [1]. Inspired by proprietary ISA's IP restrictions together with the lack of 64-bit addresses and overall complexity [2], RISC-V was developed and became more and more popular. ...
The Internet of Things (IoT) is an ongoing technological revolution. Embedded processors are the processing engines of smart IoT devices. For decades, these processors were mainly based on the Arm instruction set architecture (ISA). In recent years, the free and open RISC-V ISA standard has attracted the attention of industry and academia and is becoming the mainstream. Many companies have already owned or are designing RISC-V processors. Many important operating systems and major tool chains have supported RISC-V. Data security and user privacy protection are common challenges faced by all IoT devices. In order to deal with foreseeable security threats, the RISC-V community is studying security solutions aimed at achieving a root of trust (RoT) and ensuring that sensitive information on RISC-V devices is not tampered with or leaked. Many RISC-V security research projects are underway, but the academic community has not yet conducted a comprehensive survey of RISC-V security solutions. The latest technology and future development direction of RICS-V security research are still unclear. In order to fill this research gap, this paper presents an in-depth survey on RISC-V security technologies. This paper summarizes the representative security mechanisms of RISC-V hardware and architecture. Specifically, we first briefly introduce the background and development status of RISC-V, and compare the RISC-V mechanisms with the most relevant Arm mechanisms, highlighting their similarities and differences. Then, we investigate the security research of RISC-V around the theme of hardware and architecture security. Our survey covers hardware and physical access security, hardware-assisted security units, ISA security extensions, memory protection, cryptographic primitives, and side-channel attack protection. Based on our survey, we predict the future research and development directions of RISC-V security. We hope that our research can inspire RISC-V researchers and developers.
... Similar to compilation, the decompilation process consists of multiple phases, beginning with disassembly. Some techniques have emerged for verifying low-level aspects of decompiled binaries such as architectural semantics [50,25,13], decompilation into logic [46,47,48,54], and translation validation [24] (discussed in Sec. 8). ...
... Hendrix et al. [38] discuss their ongoing work on verifying the translation performed by their lifting tool reopt. Numerous other works (e.g., Sail [13]) provide formal semantics of ISAs. ...
There is increasing interest in applying verification tools to programs that have bitvector operations (eg., binaries). SMT solvers, which serve as a foundation for these tools, have thus increased support for bitvector reasoning through bit-blasting and linear arithmetic approximations. In this paper we show that similar linear arithmetic approximation of bitvector operations can be done at the source level through transformations. Specifically, we introduce new paths that over-approximate bitvector operations with linear conditions/constraints, increasing branching but allowing us to better exploit the well-developed integer reasoning and interpolation of verification tools. We show that, for reachability of bitvector programs, increased branching incurs negligible overhead yet, when combined with integer interpolation optimizations, enables more programs to be verified. We further show this exploitation of integer interpolation in the common case also enables competitive termination verification of bitvector programs and leads to the first effective technique for LTL verification of bitvector programs. Finally, we provide an in-depth case study of decompiled ("lifted") binary programs, which emulate X86 execution through frequent use of bitvector operations. We present a new tool DarkSea, the first tool capable of verifying reachability, termination, and LTL of such lifted binaries.
... 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. ...
Development of formal proofs of correctness of programs can increase actual and perceived reliability and facilitate better understanding of program specifications and their underlying assumptions. Tools supporting such development have been available for over 40 years, but have only recently seen wide practical use. Projects based on construction of machine-checked formal proofs are now reaching an unprecedented scale, comparable to large software projects, which leads to new challenges in proof development and maintenance. Despite its increasing importance, the field of proof engineering is seldom considered in its own right; related theories, techniques, and tools span many fields and venues. This survey of the literature presents a holistic understanding of proof engineering for program correctness, covering impact in practice, foundations, proof automation, proof organization, and practical proof development.
... Lipsi comes with two components: an instruction-set simulator and the circuit, specified in Chisel [4]. We then build both HW and SW models using respectively the Temporal Logic of Actions (TLA + ) formal specification language [20] and the Sail formal language dedicated to express ISA [1]. We detail these models, the simple timing model of Lipsi that we add in the SW model and how we add these timing invariants in the HW model of Lipsi. ...
... To formally specify hardware behavior, we use the TLA + language [20,43], as it is a high-level specification language for modeling concurrent systems and comes with a model-checker. On the SW side, we use Sail [1] to formally model programs as it is tailored for expressing Instruction-Set Architecture (ISA) semantics of processors. It has been successfully applied to formalize various ISAs, such as ARM, RISC-V and MIPS [1]. ...
... On the SW side, we use Sail [1] to formally model programs as it is tailored for expressing Instruction-Set Architecture (ISA) semantics of processors. It has been successfully applied to formalize various ISAs, such as ARM, RISC-V and MIPS [1]. The K framework, which was recently used for a formal executable semantics of x86-64 ISA [10], is another option we have not yet considered so far [2]. ...
Timing analysis of safety-critical systems derives timing bounds of applications, or software (SW), executed on dedicated platforms, or hardware (HW). The ensemble HW–SW features, from a timing perspective, two different types of computation – a SW-specific, instruction-driven timing progression and a HW-specific, cycle-driven one. The two timings are unified under a concept of timing model, which is crucial to establish a sound and precise worst-case timing reasoning. In this paper, we propose an investigation on how to systematically derive and formally prove such timing models. Our approach is exemplified on a simple, accumulator-based processor called Lipsi.
... Our contribution is to show how a formal SW ISA-level model of a processor, enriched with timing behavior, can be used to detect both functional and timing discrepancies in its implementation. We use Sail [1] to formally model programs as it is tailored for expressing ISA semantics of processors and has been successfully applied to formalize various ISAs, such as ARM, RISC-V, and MIPS. A Sail specification relies on the definition of an Abstract Syntax Type (AST) of the ISA of an architecture, i.e. a union of types with parameters. ...
... The ISS presented in [6] is symbolic and addresses both functional and timing properties in processors using assertions in a similar way with our procedure as another symbolic ISS, which is constructed over an instruction-level abstraction [11]. We can also leverage existing formal SW models, such as [1] or [8] to extend their functional parts with a timing behavior. Besides, the K framework, which was recently used for a formal executable semantics of x86-64 ISA [8], is another option we have not yet considered so far [2] to design our formal SW model. ...
