Formal Methods Need Not Be Black Magic

Joseph R. Kiniry and Daniel M. Zimmerman1st RISC-V Summit, Santa Clara, California

4 December 2018

Formal Methods Through the Ages (1 of 2)● computer science is the daughter of early 20th century mathematics/logic● hardware/computer/electrical engineering is the daughter of CS and physics● physics is the daughter of 18th and 19th century mathematics● formal methods is the application of mathematics to the problems of

computer science and systems engineering (hard-/firm-/software)

Formal Methods Through the Ages (2 of 2)

● formal methods in the 1950s–1990s was viewed as an esoteric, impossible to use discipline only fit for PhDs solving problems about toy systems and languages

● formal methods exploded into hardware verification in the late 80s and 90s due to enormously expensive failures in CPU design and testing

● even today, around twenty years later, formal methods is viewed in most hardware design houses as an esoteric, difficult to use discipline only fit for a few very expert ‘formal’ engineers solving problems for small IP blocks and antique languages like Verilog and VHDL

Advancements of ‘Formal’ in Systems Engineering

● 1950s–1990s: “esoteric”, “impossible to use”, “only fit for PhDs solving problems about toy systems and languages”

● Late 1990s: started to tackle mainstream programming languages and real systems, but it still took PhDs months of work for results

● 2000s: started to leverage modern GHz, GBs, and Gb/s, thus automation and scalability exploded and FM crept into mainstream tools● compiler semantic static checking, JVM class loading

● 2010s: started to focus on UX and mainstream integration● language, compiler, and IDE integration and UI advancements

● Now: pervasive (for software, at least), but completely hidden to engineers—almost as if someone has snuck FM into our workflows!

Secret Ninja Formal Methods (SNFM)

● ninjas are the sneakiest kids in town● Secret Ninja Formal Methods is a peer-

reviewed applied formal methods systems development methodology that we defined over a decade ago

● SNFM focuses on verification-centric system design and development

● we are now applying SNFM to hardware engineering and verification

● key idea: powerful tools hide the mathematics and expose all specification and reasoning using UIs and metaphors familiar to developers

Facets of (Secret Ninja Applied) Formal Methods

● specification: describe functional behavior or non-functional properties

● modeling: extract formal models from specifications, implementations, verification artifacts such as test benches, etc.

● implementation: build (parts of) the system according to a configuration

● execution: run (parts of) the system in simulation, on VMs, or hardware

● validation: execute (parts of) the system and evaluate properties using runtime assertion checking

● verification: check properties of a model for all inputs/environments

More like this!

Not this!

specification

modeling

implem

entation

execution

validation

verification

modeli

ng

specific

ation

executi

on

implem

entation

verifica

tion

validat

ion

SNFM Tools and Technologies for Firmware/Software

● over the past 20 years we have developed instantiations of the SNFM methodology for various platforms and languages:● Java: BON for system specs; JML for model-based specs; Java for

implementation; JMLUnitNG for validation; Eclipse/IDEA/Emacs for IDE; Beetlz+ESC/Java2+OpenJML+KeY for verification

● .NET: BON for system specs; Code Contracts for model-based specs; F#/C#/Spec# for implementation; VisualStudio/VisualStudioCode/Emacs for IDE; PEX/Moles for validation; Code Contracts for verification

● Eiffel: BON for system specs; Eiffel contracts for model-based specs; Eiffel for implementation; EiffelStudio/Eclipse/Emacs for IDE; EiffelStudio and Eve for validation and verification

SNFM Tools and Technologies for Firmware/Software

● over the past 20 years we have developed instantiations of the SNFM methodology for various platforms and languages:● SPARK: BON for system specs; SPARK contracts for model-based specs;

SPARK/Ada/C for implementation; GPS for IDE; SPARK tools for validation and verification

● C/Rust: BON for system specs; ACSL for model-based specs; C, Rust, and assembly for implementation; Eclipse/mbeddr/CLion/VisualStudio/Emacs for IDE; Frama-C and SAW for validation and verification

● Functional languages: BON for system specs, Haskell types and modules for type-based specs; Haskell/ML/Idris/Coq for specification and implementation; Emacs for IDE; QuickCheck, behavioral types, and theorem proving for V&V

SNFM Tools and Technologies for Hardware

● What tools in the hardware world use formal methods but hide all logic?● Cadence’s JasperGold and Mentor Graphics’s Questa for (System)Verilog● Clifford Wolf/SymbioticEDA’s Yosys and SymbiYosys for (System)Verilog● Galois’s SAW for Bluespec SystemVerilog (BSV)

● The BESSPIN Tool Suite (in development at Galois) features:● support for five HDLs: Verilog, SystemVerilog, SystemC, BSV, and Chisel● extraction of architecture specification from an implementation● extraction of feature model from an implementation● configuration of a feature model into a product● measurement and evaluation of PPAS (S=Security) for a family of products● evaluation of correctness and security for a family of products

Peeking Behind the Curtain (State Space Complexity)

● state space complexity is the red herring of hardware verification!● if your only reasoning technique is model checking, then the size of your state

space matters enormously (and reasoning effort is enormous!)● if you are using any one of a dozen other reasoning techniques rarely applied to

hardware, it matters much less (and reasoning effort is remarkably small!)● the kind of system you reason about and its complexity matters much more

● sequential systems● (structured/reasonable) concurrent systems● (structured/reasonable) distributed systems

● the kind of specification and reasoning that you do matters enormously● compositional● non-compositional

Peeking Behind the Curtain (Logical Complexity)

● models extracted from simple (100 LOC) programs and specifications vary widely in size:● complex programming/hardware description language:

10–100s of pages of logic● simple specification language (predicate logic or first-order logic):

a few pages of logic● complex specification language (temporal logic or model-based spec):

100s of pages of logic● models derived from real world specifications and implementations are

regularly 100–1000s of pages of logic per property

10+ Years of Case Studies in SNFM

● formally verified video games● electronic voting technologies● distributed systems frameworks● mobile agent platforms● hardware CAD technologies● embedded systems products

(IoT, smart sensor networks, etc.)● tools like interpreters, type

checkers, compilers, etc.● secure boot for RISC-V CPUs● RISC-V microcontroller-sized CPUs

A Formally Verified Cryptographic Extension to a RISC-VProcessor

Joseph R. Kinirykiniry@galois.com

Galois, Inc.Portland, OR, USA

Daniel M. Zimmermandmz@galois.com

Galois, Inc.Portland, OR, USA

Robert Dockinsrdockins@galois.com

Galois, Inc.Portland, OR, USA

Rishiyur Nikhilnikhil@bluespec.com

Bluespec, Inc.Framingham, MA, USA

ABSTRACTSecurity in computing systems is based upon having correct andsecure software, �rmware, and hardware. Formal reasoning is ca-pable of providing solid assurance about correctness and securityfor software and �rmware, and formal reasoning about hardwarecorrectness has advanced signi�cantly in recent years. However,formal reasoning about system security is in its infancy. The securityof software systems is often reliant upon cryptographic foundationsand development artifacts open to peer review, such as formal pro-tocol and algorithm speci�cations and proofs of correctness. Thesecurity of hardware systems, however, is virtually always basedupon secrecy and limited amounts of testing. RISC-V presents anopportunity to change the state of system security assurance forthe better. As a �rst step in this direction, we describe a formallyveri�ed cryptographic extension to RISC-V and its assurance case.

KEYWORDSRISC-V, cryptography, assurance, veri�cation, applied formal meth-ods

ACM Reference Format:Joseph R. Kiniry, Daniel M. Zimmerman, Robert Dockins, and RishiyurNikhil. 2018. A Formally Veri�ed Cryptographic Extension to a RISC-VProcessor. In Proceedings of Second Workshop on Computer ArchitectureResearch with RISC-V (CARRV 2018). ACM, New York, NY, USA, 5 pages.https://doi.org/10.1145/nnnnnnn.nnnnnnn

1 INTRODUCTIONFor a computing system to be secure, it must have correct andsecure software, �rmware, and hardware. Formal reasoning andrigorous development techniques are capable of providing solid as-surance about software and �rmware correctness and security. For-mal reasoning capabilities for hardware correctness have advancedsigni�cantly in recent years, and are becoming more widely used.However, formal reasoning about hardware security and system

Permission to make digital or hard copies of part or all of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor pro�t or commercial advantage and that copies bear this notice and the full citationon the �rst page. Copyrights for third-party components of this work must be honored.For all other uses, contact the owner/author(s).CARRV 2018, June 2, 2018, Los Angeles, California, USA© 2018 Copyright held by the owner/author(s).ACM ISBN 978-x-xxxx-xxxx-x/YY/MM.https://doi.org/10.1145/nnnnnnn.nnnnnnn

security (i.e., the security of particular combinations of software,�rmware, and hardware) is in its infancy.

In software, security assurance cases typically rely upon wellstudied cryptographic foundations and development artifacts opento peer review, such as formal protocol speci�cations, formal algo-rithm speci�cations, and proofs of correctness. In hardware, how-ever, security assurance is nearly always based upon secrecy andlimited amounts of testing, with no formal proofs and minimal, ifany, peer review.

The open RISC-V ecosystem presents an opportunity to changethe state of system security assurance for the better, by enabling forhardware the open peer review and independent formal veri�cationalready available for high assurance software. As a proof of thisconcept we have built a formally veri�ed cryptographic extensionto RISC-V, incorporated it into a small system, and developed anassurance case spanning the system’s hardware, �rmware, andsoftware. Here, we primarily describe the cryptographic extensionand the assurance techniques we used to verify its correctness,as compared to typical assurance techniques used for validatedcryptographic systems.

2 CRYPTOGRAPHIC IMPLEMENTATIONASSURANCE

2.1 The Status QuoAssurance in today’s hardware and software cryptographic im-plementations is primarily achieved through validation againstnational standards like the U.S. Federal Information ProcessingStandard 140-2 [11] (FIPS 140) and associated Implementation Guid-ance [12]. FIPS 140, which has not been updated since 2001, has 4levels (called simply “Level 1” through “Level 4”). At the lowest se-curity level (Level 1), validation requires the presence of structureddocumentation of various kinds for the system’s cryptographicfunctionality, and that the system passes all relevant tests man-dated by the NIST Cryptographic Algorithm Veri�cation Program(CAVP). At higher security levels, validation also requires physicaltamper-evidence and role-based authentication (Level 2); physicaltamper-resistance, identity-based authentication, and a separationbetween the module’s interfaces for “critical security parameters”and its other interfaces (Level 3); and stricter physical security

Secret Ninja Formal Methods

Joseph R. Kiniry1 and Daniel M. Zimmerman2

1 School of Computer Science and Informatics, University College Dublin,Belfield, Dublin 4, Ireland, kiniry@acm.org

2 Institute of Technology, University of Washington, Tacoma,Tacoma, Washington 98402, USA, dmz@acm.org

Abstract. The use of formal methods can significantly improve softwarequality. However, many instructors and students consider formal meth-ods to be too di�cult, impractical, and esoteric for use in undergraduateclasses. This paper describes a method, used successfully at several uni-versities, that combines ninja stealth with the latest advances in formalmethods tools and technologies to integrate applied formal methods intosoftware engineering courses.

1 Enter the Ninja

Software development tools and techniques based on formal methods hold greatpromise for improving software quality. Unfortunately, many undergraduate com-puter science and software engineering curricula include no formal methods in-struction beyond the introduction of basic concepts such as the assertion and theloop invariant. Moreover, even when formal methods concepts are introduced,they tend not to be used outside of toy examples. Many students and instructors,it seems, believe that the very words “formal methods” imply writing equationson paper for hours on end with no computers in sight. Those who have neverused modern formal tools and techniques generally consider formal methods tobe irrelevant to “real” computer programming.

Our goal is not only for our students to use formal methods in their softwaredesign and implementation process, but also for them to enjoy doing so. To ac-complish this lofty goal, we employ shinobi-iri3 (stealth and entering methods)—we sneak up on our blissfully unaware students, slip a dose of formal methodsinto their coursework and development environments, then with a thunderclapdisappear in a pu↵ of smoke.

We teach our students to design software systems using a (formal) notationthat appears to be merely structured English, and to implement them using so-phisticated tool support that is almost entirely hidden behind simple instructor-provided scripts and IDE plugins. Details about the automated theorem proving,static code analysis, runtime assertion generation, and other processes underly-ing the system are not revealed to the students until after they have implemented3 The terminology of the ninja may be inscrutable to the uninitiated; the

curious reader may more intensively exercise his choho (espionage skill) athttp://en.wikipedia.org/wiki/Ninjutsu.

Ensuring Consistency between Designs, Documentation,Formal Specifications, and Implementations

Joseph R. Kiniry and Fintan Fairmichael

School of Computer Science and Informatics andCASL: The Complex & Adaptive Systems Laboratory,University College Dublin,Belfield, Dublin 4, Ireland

kiniry@acm.org and fintan.fairmichael@ucd.ie

Abstract. Software engineering experts and textbooks insist that all of the artifacts related to a system,(e.g., its design, documentation, and implementation), must be kept in-sync. Unfortunately, in the realworld, it is a very rare case that any two of these are kept consistent, let alone all three. In general,as an implementation changes, its source code documentation, like that of Javadoc, is only occasion-ally updated at some later date. Unsurprisingly, most design documents, like those written in UML,are created as a read-only medium—they reflect what the designers thought they were building at onepoint in the past, but have little to do with the actual running system. Even those using formal methodsmake this mistake, sometimes updating an implementation and forgetting to make some subtle changeto a related specification. The critical problem inherent in this approach is that abstraction levels, whiletheoretically inter-dependent, are actually completely independent in semantics and from the point ofview of the tools in pervasive use. Entities in different layers have no formal relationship; at best, in-formal relations are maintained by ad hoc approaches like code markers, or code is generated once andnever touched again. This paper presents a new approach to system design, documentation, implemen-tation, specification, and verification that imposes a formal refinement relationship between abstractionlevels that is invisible to the programmer and automatically maintained by an integrated set of tools.The new concept that enables this approach is called a semantic property, and their use is discussedin detail with a set of examples using the high-level specification language EBON, the detailed designand specification language JML, and the Java programming language as the implementation language.

1 Introduction

Ad hoc constructs and local conventions have been used to annotate program code since the invention ofprogramming languages. The purpose of these annotations is to convey “extra” programmer knowledge toother system developers and future maintainers. These comments usually fall into that grey region betweencompletely unstructured natural language and formal specification. For example, an ad hoc conventionpromoted by Eclipse are the FIXME, TODO, and XXX task tags that cause errors or warnings to appear inEclipse’s Problems view.

Invariably, such program comments rapidly exhibit “bit rot”. Over time, these comments and the im-plementation to which they refer diverge to an inconsistent state (a process often referred to as erosion ordrift [1]). Unless they are well maintained by documentation specialists, rigorous process, or other extra-mile development efforts, they quickly become out-of-date. They are the focus for the software engineeringmantra: an incorrect comment is worse than no comment at all.

Recently, with the adoption and popularization of lightweight documentation tools in the literate pro-gramming tradition [2,3], an ecology of semi-structured comments is flourishing. The rapid adoption andpopularity of Java primed interest in semi-structured comment use via the Javadoc tool. Other similarcode-to-documentation transformation tools have since followed in volume, including Jakarta’s Alexan-dria, Doxygen, and Apple’s HeaderDoc. SourceForge reports dozens of projects with “Javadoc” in theproject summary, and FreshMeat reports several dozen more, with some overlap.

While most of these systems are significantly simpler than Knuth and Levy’s original CWEB, theyshare two key features.

Firstly, they are easy to learn, since they necessitate only a small change in convention and process.Rather than forcing the programmer to learn a new language, complex tool, or imposing some other signif-icant barrier to use, these tools actually reward the programmer for documenting their code.

A Verification-centric Software Development Process for Java

Daniel M. ZimmermanInstitute of Technology

University of Washington TacomaTacoma, Washington 98402, USA

Email: dmz@acm.org

Joseph R. KinirySchool of Computer Science and Informatics

University College DublinBelfield, Dublin 4, Ireland

Email: kiniry@acm.org

Abstract

Design by Contract (DBC) is an oft-cited, but rarelyfollowed, programming practice that focuses on writingformal specifications first, and writing program code thatfulfills those specifications second. The development of staticanalysis tools over the past several years has made itpossible to fully embrace DBC in Java systems by writing,type checking, and consistency checking rich behavioralspecifications for Java before writing any program code.This paper discusses a DBC-based, verification-centric soft-ware development process for Java that integrates the Busi-ness Object Notation (BON), the Java Modeling Language,and several associated tools including the BON compilerBONC, the ESC/Java2 static checker, a runtime assertionchecker, and a specification-based unit test generator. Thisverification-centric process, reinforced by its rich opensource tool support, is one of the most advanced, concrete,open, practical, and usable processes available today forrigorously designing and developing software systems.

1. Introduction

Design by Contract (DBC) [1] is a design technique for(usually object-oriented) software that uses assertions bothto document and enforce restrictions on data and to specifyclass and method behavior. The Business Object Notation(BON) [2] is an analysis and design notation for object-oriented systems based on DBC. Both were originally de-veloped for use with the Eiffel programming language; DBChas since been added to many other programming languagesthrough various language extensions and preprocessors.

Ideally, developers using the DBC technique write formalspecifications (the contracts) for their software first, andwrite executable code only after completing, and performingat least some basic checking of, the contracts. However, toolsupport for DBC has until recently been limited primarilyto runtime assertion checkers and unit test generators. Therehas been little support, beyond basic type checking, forverifying the logical consistency of contracts that have noimplementations. In essence, the “design” component ofDBC has been absent; DBC has meant writing contracts

and code in tandem and using runtime assertion checking(RAC) and generated unit tests to check the contracts andcode simultaneously. Unfortunately, when code is written inthis way, it is often difficult to determine whether problemsdetected by RAC and unit testing are caused by errors inthe code or by errors in the contracts.

In recent years, however, the tool landscape has changedsignificantly. The Java Modeling Language [3] (JML) hasenabled both DBC and additional model-based specificationsfor Java programs, and the ESC/Java2 static checker hasbeen extended to support the entirety of JML [4]. Addi-tionally, a variety of static checkers have been added toESC/Java2 to support reasoning about specifications. Thesetools allow developers to write, type check, and staticallycheck the consistency of rich behavioral specifications beforewriting any program code.

The combination of BON and DBC (for design),ESC/Java2 and other tools (for static checking), and RACand the automatic generation of unit tests from specifications(for runtime checking) results in a verification-centric de-velopment process, in which verification of both behavioralspecifications and program implementation occurs continu-ously throughout development. This process supports the en-tire range of development artifacts via refinement, includingconcepts, requirements, feature models, types, mathematicalmodels, informally and formally annotated source code,and formally annotated object code. We have previouslydiscussed our use of ninja techniques to teach this processto our software engineering students [5]; here, we presentthe steps of this process from the practitioner’s perspective,along with more detail about the critical tools and techniquesinvolved. We also present process guidelines, including ourcode standard and our testing requirements.

2. Background

Our verification-centric software development process in-corporates several tools and techniques. In this section, weintroduce and provide background on the most important ofthese. Much more information is available in the cited worksand in the documentation accompanying the tools.

SNFM and RISC-V

● formally verified secure boot for Bluespec’s Piccolo RV32I RISC-V

● ongoing work on rigorously validating and formally verifying arbitrary RISC-V CPUs (particularly the three CPU variants in SSITH, a 32b microcontroller, a 64b desktop CPU, and a 64b superscalar server CPU)

● the BESSPIN Tool Suite itself, which facilitates PPAS (power, performance, area, and secure) evaluation of SoCs

© 2018 Galois, Inc.‹#›

© 2018 Galois, Inc.

Our Case Study

�11

18

to the hardware for the software. In particular, it handles the mapping of software buffers to hardware memory regions for performing encryption or decryption. The software is responsible for all top-level functionality, including device configuration and data streaming. The demonstrator’s architecture and main constituent subsystems are summarized in Figure 6.

Figure 6 The SHAVE Demonstrator System Architecture

3.4.2 Assurance. A formal assurance case is provided for each layer, and each layer’s

assurance case provides guarantees to the layer above and relies upon guarantees provided by the layer below. Assurance is provided in several forms, ranging from traceable specifications of capabilities and requirements to implementations and evidence to runtime verification with manually-written and automatically-generated test harnesses to formal mathematical proof of security and correctness properties.

3.4.3 Hardware. The hardware layer is the SHAVE Secure Processor—a 32 bit RISC-V chip with a cryptographic hardware extension that is effectively an AES128 native instruction. The RISC-V chip that we use is Bluespec’s Piccolo architecture, which implements the RISC-V ISA RV32I and privilege levels U and M. It is a simple 3-stage in-order pipeline.

The SoC that we simulate is Bluespec’s 2nd generation SoC which includes as a part of its fabric DRAM with a memory controller, a timer, a UART, and a hardware accelerated AES128 implementation. As this SoC is built with Bluespec’s RISC-V Verification Factory, we are able to load new binaries, run, debug, and interact with programs in the SHAVE Secure Processor as it runs in simulation (in a Verilog simulator) or on an FPGA board (a Xilinx Kintex-7, in particular).

HARDWARE RISC-VCPU

AESNI

FIRMWARE

SOFTWARECRYPTO LIBRARY

NO OPERATING SYSTEM

STREAMING ENCRYPTIONAPPLICATION

CRYPTO FIRMWARE

softwareC code

behavioral spec

(ACSL/Cryptol)

architecture spec

(BON)

firmware C code

behavioral spec

(ACSL/Cryptol)

architecture spec

(BON)

RISC-V in BSV

BSV in Coq

AES in BSVAES in Cryptol

AES in SV

library theory

(Cryptol)

firmware theory

(Cryptol)

RISC-V in SV

© 2018 Galois, Inc.‹#›

© 2018 Galois, Inc.

Product Line Engineering and Assurance

• treat the entire system as a product line for design, development, and assurance

�16

SHAVE Secure CPU

Security Architecture

Group

RISC-VCPU

ARM CPU

ISA Groupwidth = 32

Tagged Scope Group

DRAM

Registers ICache

DCache

Tagged Architecturesize: ℕ Crypto Group

AES SHA2

Symmetric Cipher Group

keysize: 128blocksize: 128

MD5

RNG Group

Hash Group

blocksize: ℕ

Asymmetric Cipher Group

keysize: ℕblocksize: ℕ

3DES

RSA

ElGamal

PRNG TRNG

RISC-V Group

Z-scale

Rocket BOOM

Piccolo

kind: hwassurance: verified

Be a Ninja? Be a Ninja!

● the core of being a ninja is accepting in your heart thinking before doing● understand what you want to create & describe it before you start coding● describe your system using artifacts that create evidence● descriptions for hardware are test, validation, and verification benches● design and build for verification

● we want more ninjas in the world! dive in! get involved! ● get a broader perspective and learn more about what has happened in

the world of applied formal methods and rigorous systems engineering ● experiment with free rigorous validation and verification tools ● contribute to open source tools for hardware design—don’t be resigned

to the current state of the industry