Assurance through Enhanced Design Methodology Orlando, FL 5 December 2012 Nirav Davé SRI International This effort is sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contract FA C This material is approved for public release, distribution unlimited. The views expressed are those of the authors and do not reflect the official policy or position of the Department of Defense or the U.S. Government.

The Problem We want designers to build systems: That work That are fast That are cheap That are fast to develop Designers do not want more responsibility Adding a strong correctness / verification is a “want” but not a “need” and so we have a high resistance to adoption

Convincing Designers to do extra work We could simply force designers to use the “right” methodology / tool / etc., but engineers are very good at technically meeting requirements The only way to get high assurance is to convince designers that its worth it for their bottom line

Examples Static Type Checking Eradicates a huge slew of usage errors Garbage Collection Coverage-based test generation Automatic generation of tests

BSV: State and Rules organized into modules All state (e.g., Registers, FIFOs, RAMs,...) is explicit. Behavior is expressed in terms of atomic actions on the state: Rule: guard  action Semantics: Repeatedly any rule with valid guard & execute it interface module

Better Design Abstraction: Bluespec SystemVerilog Corresponds to cycle-level parallel operations designers reason about (not FSMs) Directly exposes error prone micro-scheduling task of hardware and provides high performance schedule. Greatly enhances ability to modular refine designs A decade of work showing: No Compromise Hardware Substantially smaller (2-10x) code Increased readability and modifiability

Automatic extraction of architectural behavior Can leverage the fact that operations are directly represented to easily fuse micro-operations split for performance back to a ISA-level operation: Can easily abstract away pipelining, caching, speculation, etc. Dramatically simpler verification of ISA properties Exposes interesting execution paths: focuses debugging efforts

Compartimentalizing Application stack 15

Software compartmentalisation Software compartmentalisation decomposes applications into many isolated components. Each running with only the rights required to perform its function. This implements the principle of least privilege. When a compartmentalised application is compromised, only rights held by the exploited component leak to the attacker. Most vulnerabilities will no longer yield significant rights, and attackers must exploit many vulnerabilities to meet their goals. When a compartmentalised application is compromised, only rights held by the exploited component leak to the attacker. Most vulnerabilities will no longer yield significant rights, and attackers must exploit many vulnerabilities to meet their goals. When a conventional application is compromised, its ambient rights are leaked to the attacker, e.g., full network and file system access. Software implementation quickly becomes prohibitively expensive

CHERI: HW Capabilities Hardware-based capabilities to make compartment boundary changes cheap enough to scale to large numbers Capabilities provide type safety and object-capability invocation within user processes & avoid multi-process compartmentalization Pro: higher assurance Con: additional user requirement to get benefits. High-level Language solutions possible.

Conclusion We’ve known what we need to get higher assurance for years Low adoption as long as it’s not a base requirement for any design, unless techniques which improve assurance also simplify the designers task