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 FA8750-11-C-0249. 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

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.

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