formal methods need not be black magic (2018 risc-v summit) · formal methods need not be black...
TRANSCRIPT
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. [email protected]
Galois, Inc.Portland, OR, USA
Daniel M. [email protected]
Galois, Inc.Portland, OR, USA
Robert [email protected]
Galois, Inc.Portland, OR, USA
Rishiyur [email protected]
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, [email protected]
2 Institute of Technology, University of Washington, Tacoma,Tacoma, Washington 98402, USA, [email protected]
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
[email protected] and [email protected]
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: [email protected]
Joseph R. KinirySchool of Computer Science and Informatics
University College DublinBelfield, Dublin 4, Ireland
Email: [email protected]
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