safe - a clean-slate, secure computing platform€¦ · safe - a clean-slate, secure computing...

SAFE - A Clean-Slate, Secure Computing Platform

Approved for Public Release; Distribution Unlimited. Cleared for Open Publication on 06/11/14.

AFRL Safe and Secure Systems and Software Symposium (S5).

Dayton, Ohio USA, June 12, 2014

Presenter: Greg Sullivan, BAE Systems, [email protected]

with the University of Pennsylvania, Harvard University, and Northeastern University

mailto:[email protected]

Outline

• SAFE Prehistory • SAFE Vision • SAFE Design • SAFE Status • What next? • Summary

SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 2

Computer History • Smaller, cheaper, faster • Pervasive


Did I mention security? No.

SAFE History

Cyber Insecurity

It’s bad.

It’s going to get worse. SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 4

SAFE History

Not Solutions P4I – “Perimeter Protection, Patch, and Pray”

Do you feel safer now? SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 5

Probably not. What’s the I?

SAFE History

Status Quo: Deadlock • Computer architecture: smaller, cheaper, faster

– Even if add security features to hardware, languages and OS broken – Complex (Baroque memory subsystem to support multicore, etc.)

Backwards compatibility constraints – “Raw, seething bits” – no (secure) metadata on which to base security

• Programming languages: Security features subverted by vulnerable OS, poor HW support

• Operating systems: huge installed base. Security features easily subverted by insecure base. Extremely difficult to formalize and verify (due to PLs, memory model, etc.)


A vulnerability at any level seems to subvert the security of the entire system.

SAFE History

Stuck in a local maximum

SAFE Vision Clean Slate • Take “Clean Slate” mandate seriously • Deliberately explore unexplored regions

of (HW, PL, OS) design space

Co-Design • Attempt to break HW-PL-OS deadlock • Find virtuous cycles

Formal Methods • Include formal specification and verification

in Co-Design


SAFE Vision

QED.

Root Causes of Computer Insecurity • Memory is “raw seething bits”

– Can forge addresses, instructions – Nowhere to securely store

security properties

• Single point of failure – Any single exploit gets

you root

A computer system cannot enforce policies it does not know about.


0x 1 F A B C 0 1 2 3

What is this? • Integer? • Pointer? • Instruction? • If a pointer, can this thread

dereference it? • Copy bytes to it? How many?

• Can this thread send value over a socket? Does it matter what’s on other end of socket?

Solutions • Fine-grained compartmentalization

– Isolation of effects, information • (Asymptotically) Zero kernel OS

– Mutually suspicious, least privilege, cooperating federation. No single point of failure. No “root”.

• Resources as capabilities – Unforgeable addresses, instructions, etc.

• Policy enforcement – Data flow secrecy and integrity – Control flow integrity (rule out, e.g. ROP). – Object integrity (rule out, e.g. buffer overflow) – Application level policies – compiled to hardware

mechanisms SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 9

And… We Want

Proof!

SAFE Design

Mechanisms

• Metadata tagging – Primitive Types

(instruction, address, data, …) – Fat Pointers – Programmable Tags

• Ownership/acl, type, usage, IFC, provenance, …

• Fast domain crossing – Gates: a single mechanism for

updating current authority


Trade Silicon for Security

0x 1 F A B C 0 1 2 3 0x 2 3 4 0 0 0 1 2 3 0 8

Atomic Group 08 = “Pointer to Frame of memory”

Fat Pointer Encoding of Addresses “Pointer is to memory starting at 0xABC of size 123” (notional).

Label (only readable in Tag Manager) Secrecy: Bob or Alice can read Integrity: Endorsed by WebServer

One Indivisible Atom – Three Parts

SAFE Design

Checks at Every Instruction

• So now, what is this? • Check that R2 is a pointer (atomic group 08)

– Also check that R1 is an integer, and R2+R1 < bounds *R2

• The tag points to a structure that requires that Alice authority be installed to access the value – Check authority register of machine

• The tags are sent to the Tag manager, which checks access and calculates tag for result

• For example [Alice or Bob] + [Alice] ⇒ [Alice]

SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 11 Trade Silicon for Security

0x 1 F A B C 0 1 2 3 0x 2 3 4 0 0 0 1 2 3 0 8 offp R1 R2 PC R2

SAFE Design

Efficient Fat Pointers • Compact encoding

– 64bit word for a 46bit address • Force alignment; floating-point

like length – 3% memory fragmentation

• Hardware bounds check – Operates in parallel with

other units, like ALU – Rules out buffer overflows

• Pointer as capability – Can only address segment

if given pointer

12 SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons.

CCS 2013

SAFE Design

TMU Cache • Tag Management Unit caches access+IFC

queries


FPGA 2013

SAFE Design

Process Tags in Parallel


Trade Silicon for Security No need to trade speed for security

SAFE Design

SAFE Microarchitecture


Running on an FPGA

SAFE Design

SAFE Zero Kernel Operating System • Automatic memory management • No shared memory between threads • Principals, Authorities, and Tags (PAT) server • Least privilege OS components

– only allocator can forge pointer

– only scheduler can set current thread ptr.

– only PAT server can deref tags as pointers

– etc. SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons.

16

SAFE Design

Encapsulation via Gates, Threads Gates: • Single HW mechanism to

change authority • Gate closure: 3 atoms • Gate environment holds

capabilities accessible only to gate

• Same cost as procedure call


Threads: • No shared memory between

threads • Thread local gate stack, register

set • Stack is not inspectable by user

code • Thread local memory

management, including garbage collection

TSRead, SecDeclass, …

Data only accessible within gate

Code for this gate

Authorities Env PC Gate

Gate Stack Registers Handlers

PC Memory Alloc/GC

Thread

SAFE Design

Verification / Formal Methods • Overall goal: Noninterference for “concreteware” – the

abstract machine presented by verified software running on label-aware hardware

Abstract Machine (instructions operating on

labeled data)

Concrete Machine (ISA)

Software (Assembly Language)

+

Refin

es

1. Prove abstract machine noninterference

2. Prove concrete machine + software (“concreteware”) refines abstract machine.

⇒ Concreteware preserves noninterference*

* Only holds for sequential machines we are currently considering


SAFE Verification

Verification Progress

• We have proven that a simplified version of SAFE architecture, plus PAT server software, preserves Termination Insensitive Noninterference (TINI)


POPL 2014

SAFE Verification

SAFE Next • There is a long list of things we want to do • Networking

– An onboard network stack would be a compelling example of least privilege design

• General story (and demonstration) of device drivers on SAFE – Especially DMA (Direct Memory Access)

• Breeze compiler (via Tempest) • Persistent storage • SAFE-to-SAFE comms SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 20

Require crypto and some sort of “canonicalization”

What’s Next

SAFE Next, Continued

• Adding TMU to conventional processor – “PUMP” (Programmable Unit for Metadata

Processing) papers

• Verification work on micro policies – Based on PUMP work

• Use LLVM compiler infrastructure – Conventional language ⇒ SAFE via Tempest – Breeze (or Tempest) ⇒ Intel or ARM


What’s Next

SAFE Scenarios • Three overall scenarios:

1. SAFE as “pillars of trust” in e.g. SOUND-enhanced distributed system

2. SAFE “secure data processor” as front-end to database 3. SAFE for embedded systems

• Glucose monitor • Smart phones. E.g. Project Ara at Google


What’s Next

SOUND Cloud Un-

SAFE SAFE

Un-SAFE

Un-SAFE

Un-SAFE

Un-SAFE

SAFE Data Store

SAFE preserves information flow

labels and enforces policies

Network

SAFE

SAFE

SAFE – The Case for Clean Slate • Hardware can immediately guarantee:

– no buffer overflows – no code injection

• Software-defined rules, with hardware support, can securely, and with good performance, implement: – Control flow integrity (no ROP) – Mandatory access control – Information flow control (secrecy, taint, provenance,

endorsement, integrity) – Application-defined security compartments (e.g. S, TS, SCI,

per user, etc.) • Formal methods can achieve an extremely high degree of

confidence in security, backed up by hardware


Summary

Stop Complaining. Do Something. • Stop whining about the difficulty of fixing current systems

(in fact, they are impossible to fix) • We know how to design and build extremely secure

systems, at the expense of silicon but not performance: • Hardware interlocks for universal security • Hardware-mediated software-defined information flow

and access control policies • Formal verification to prove correct adherence to

policies • It is imperative that we push forward

• The payoff in increased security is huge • The loss due to the inevitable exploitation of

conventional systems would be unfathomable


Summary

SAFE: Clean Slate HW, PL, OS

System Services (device drivers,

networking, storage)

User Programs

Memory Manager / GC

TMU Manager Scheduler IPC

HardWare (written in Bluespec)

SAFE Processor

TMU Rule Cache

Stock TPM

UserWare (written in

Breeze)

ConcreteWare (in Tempest, Assembly)

Breeze Compiler

Proofs

Formal Semantics


http://www.crash-safe.org/


http://www.crash-safe.org/

safe - a clean-slate, secure computing platform€¦ · safe - a clean-slate, secure computing...

Documents