Advanced Development of Certified OS Kernels

Zhong Shao Bryan FordYale University

November 2010

http://flint.cs.yale.edu/ctos

Focus Areas: Operating Systems, Programming Languages, Formal Methods

Certifying a computing host?

Formal proofs for resilience,

extensibility, security?

Need to reason about:

• human behaviors

• cosmic rays + natural disasters

• hardware failure

• software

VIEW #1: bug-free host impossible. Treat it as a biological system.

Certifying a computing host?

Formal proofs for resilience,

extensibility, security?

Need to reason about:

• human behaviors

• cosmic rays + natural disasters

• hardware failure

• software

VIEW #2: focus on software since it is a rigorous mathematical entity!

HW & Env Model

Certified software?01011010101010101111100011001110110111111101010101010101010101010111111111010101010101111000110001010101010101011111100011001001111001111111100111111100011110001010101011111101110011001110101010111111100011110001110001110011

SOFTWARE

Formal specs & proofs for resilience,

extensibility, security?

HW & Env Model

Find a mathematical proof showing that

if the HW/Env follows its model, the software will run according to its specification

010110101010101011111000110011101101111111010101010101010101010101111111110101010101011110001100010101010101010111111000110010011110011111111001111111000111100010101010111111011100

110011101010101111111000111100

Application & other system SW

Certified OS kernel?

Formal specs & proofs for resilience,

extensibility, security?

HW & Env Model

TODO:

design & develop new OS kernel that can “crash-proof” the entire SW

0101101010101010111110001100111011011111110101010101010101010101011111Certified kernel SW

need new programming language for writing certified kernels

need new formal methods for automating proofs & specs

Our approach• Clean-slate OS kernel design & development

– extensibility via certified plug-ins– resilience via history-based accountability & recovery– security via information flow control

• New PLs for building certified kernels– vanilla C & assembly but w. specialized program logics– DSL-centric framework for certified linking & programming – new DSLs & history logics for certifying kernel plugins

• New formal methods for automating proofs & specs– VeriML and type-safe proof scripts– automated program verifiers & tools

Clean-slate kernel design• No more “base kernel” per se

– it is nothing but interacting plug-ins

• The entire kernel is composed of modular, replaceable, and individually certifiable plug-ins

• Different plug-in classes implement different kernel functions --- embodying different safety and correctness model– device drivers for specific types of HW

– resource managers (schedulers, memory managers, file sys)

– protected executors implementing different secure “sandboxes”

– boot loaders and initialization modules

Extensibility via certified plug-ins

ResourceManagers

ProtectedExecutors

DeviceDrivers

Certified Kernel

CPU CPU GPU GPU Disk NIC

NativeExecutor

TypesafeExecutor

VMMExecutor

SFIExecutor

Scheduler Scheduler

Driver Driver

FS Net

DriverDriver

LegacyX86App

Java/MSILApp

NaClApp

LegacyOS + App

• each kernel extension is not just “safe” but also “semantically correct”

• protected executors replace the traditional “red line”

• efficient nested virtualization and inter-process communication (IPC)

History-based accountability• Novel kernel primitives & executors for supporting resilience

– keep a complete history log

– replay, backtrack, recover as we wish

• How to make this efficient?– enforce “determinism” to avoid logging nondeterministic events

– system-call atomicity for consistent check-pointing (as in Fluke)

• New techniques for history optimization & compression

Information flow control (IFC)• New kernel primitives for explicit control of IFC labels

– follow previous work on HiStar & Loki

– but want to have the security monitors (or plug-ins) certified

– and also enforce IFC across heterogeneous “executors”

– challenge: how language-based IFC (eg Jif) differs from OS-based ones?

• New techniques addressing covert timing channels– timeshare the processes without restriction

– but enforce “determinism” to prevent each process from reading the time

– a “read time” request would lead to an IFC “taint” fault

– the handler will migrate the process to a non-time-shared CPU

Outline of this talk• Clean-slate OS kernel design & development

– extensibility via certified plug-ins– resilience via history-based accountability & recovery– security via information flow control

• New PLs for building certified kernels– vanilla C & assembly but w. specialized program logics– DSL-centric framework for certified linking & programming – new DSLs & history logics for certifying kernel plugins

• New formal methods for automating proofs & specs– VeriML and type-safe proof scripts– automated program verifiers & tools

• certified software (proof + machine code)

• dependability claim & spec

• HW & env model

• mechanized meta-logic

• proof checker

Components of a certified framework

Proof checker

Dependability claim & spec

Proof

machine code

Yes

No

CPUs

Devices & Memory

Human & the Physical World

HW & env model

OS

timer

KBD

.

.

.

scheduler

spawn, yield, exit, lock, monitors, …

…ctxt ctxt ctxt

.

.

.interrupts

… threads

Case study: a Mini-OS

33 MHz

bootloader

1300-line 16bit x86 code,

Bootable!

How to certify this code?

Certifying the Mini-OS

Many challenges:

Many different features

Different abstraction levels

Device drivers / IO

1300 lines of code

Code loading

Low-level code: C/Assembly

Certifying the whole system

InterruptsConcurrency

bootloader

scheduler

timer int. handler

keyboard driver

keyboard int. handler

thread lib: spawn, exit, yield, …

sync. lib: locks and monitors

…

L1

L2

L3

L4

Domain-specific program logics• One logic for all code

– Consider all possible interactions.– Very difficult!

• Reality: domain-specific logics– Only limited combinations of

features are used.– It’s simpler to use a specialized

logic for each combination.– Interoperability between logics

For each DSL, use as much automation as possible!

OCAP

Our solution

Ln…L1

Mechanized meta-logic

Formalized HW & env model

…C1 Cn

C1C1

Cn

…OS

Cn

…C1 Cn

A toy machine

I1f1:

I2f2:

I3f3:

…(code heap) C

0

r1

1 2 …

r2 r3 … rn

(data heap) H

(register file) R

(state) S

addu … lw … sw … … j f

(instr. seq.) I

(program) P::=(C,S,pc)

::=(H,R)::={f I}*

pc

Program specifications

I1f1:

I2f2:

I3f3:

…(code heap) C

0

r1

1 2 …

r2 r3 … rn

(data heap) H

(register file) R

(state) S

addu … lw … sw … … j f

(instr. seq.) I

(program) P::=(C,S,pc)

::=(H,R)::={f I}*

pc

1

2

3

(spec) ::= {f }*

Mechanized meta-logic

OCAP Rules

Ln…

Domain-specific logics

Formalized HW & env model

L1

…C1 Cn

may use different How to link modules?

How to link modules?

{r1:1, …, rn:n} {P}_{Q}

call f

( _ )t

a

( _ )h

a'

…

…

f:…

…

{r1:1, …, rn:n} {P}_{Q}

( _ )t

a

( _ )h

a'

How to link modules (cont’d)?

How to define interpretation?Encode the invariant enforced in our invariant-based proof methodology.

a should be expressive enough to encode Inv.

OCAP Inference Rules

The OCAP framework [TLDI'07,VSTTE’08]

Ln…L1

…C1 Cn

( )L1 ( )LnSoundSound

OCAPSoundness

Mechanized meta logic

Formalized HW & env model

XCAP

SCAPTAL …AIM

an Open framework for Certified Assembly Programming

DSLs for writing certified plug-ins

• SCAP: stack-based control abstractions [PLDI’06]

• SAGL: modular concurrency verification [ESOP’07]

• CMAP: dynamic thread creation [ICFP’05]

• XCAP: embedded code pointers [POPL’06]

• GCAP: dynamic loading & self-modifying code [PLDI’07a]

• Certified garbage collectors & linking w. mutators [PLDI’07b,TASE’07]

• Certified context switch libraries [TPHOLs07]

• AIM: preemptive thread impl. w. HW interrupts [PLDI’08,VSTTE’08]

• Certified code running on relaxed memory models [ESOP’10]

• HLRG: certified code w. optimistic concurrency [CONCUR’10]

See http://flint.cs.yale.edu for more details

New OCAP & DSLs• More realistic HW & environment modeling

• Extend OCAP to certify advanced security & correctness properties– semantic model parameterized over the HW & env semantics

– identify invariants for different plug-in classes & executors

– certified linking of heterogeneous components

• New DSLs to certify kernel plug-ins– virtual memory management

– thread & process management & IPC

– file system

New OCAP & DSLs (cont’d) • New DSLs for deterministic concurrency

• New DSLs for informational flow control (IFC)– language-based IFC vs OS-based IFC

– variable- vs file or process granularity

– relationship w. rely-guarantee & concurrent separation logic

• New DSLs for persistence, recovery, and SW transaction– based on our new history logic HLRG [CONCUR’10]

– combining temporal reasoning with local rely-guarantee

– pre/post conditions and invariants specify history traces

Outline of this talk• Clean-slate OS kernel design & development

– extensibility via certified plug-ins– resilience via history-based accountability & recovery– security via information flow control

• New PLs for building certified kernels– vanilla C & assembly but w. specialized program logics– DSL-centric framework for certified linking & programming – new DSLs & history logics for certifying kernel plugins

• New formal methods for automating proofs & specs– VeriML and type-safe proof scripts– automated program verifiers & tools

Certified thread impl. in Coq [PLDI’08]

Coq (Higher-Order Logic with Inductive Def.)

x86 semantics (a subset)

Sep. Logic Utilities (e.g. Queues)

Around 82,000 lines of Coq code

3,300

6,300 4,000

OCAP

AIM Logic & Soundness SCAP

Locks, Condition variablesTimer handler, yield/sleep switch, block, unblock

1,700

1,30026,000

26,000 12,000

See http://flint.cs.yale.edu/publications/aim.html

Related projects• seL4 [Klein et al SOSP’09] in Isabelle/HOL

– 8700 lines of C and 600 lines of assembly– 7500 lines of C certified in 24 person years – the rest is not certified (assembly, initialization & virtual memory)– no concurrency, interrupts, mem alloc in the kernel

• Verve [Yang & Hawblitzel PLDI’10] in Boogie/Z3– 1400 lines of assembly (nucleus) + C# kernel from Singularity – the nucleus certified in 9 person months– C# kernel compiled to TAL via a type-preserving compiler– no proof objects; linking not certified; no meta theory for TAL

Challenge: need both automation (from first-order provers) & expressiveness (from Coq / HOL)

VeriML [ICFP’10]

• Proofs are more effectively done by writing new tactics: we define them as “functions that operate on logical terms (specs & proofs) and

produce other logical terms”

• VeriML --- a new general purpose PL for manipulating logical terms– ML core calculus (keep expressivity)– extended w. dependent types for logical terms – but can still “operate on” logical terms– use a logic similar to HOL w. inductive defs & explicit proof objects

• VeriML type system guarantees validity of logical terms & safe handling of binding

See http://flint.cs.yale.edu/publications/veriml.html

VeriML vs CoqThree ways to write tactics:

• ML– untyped tactics, high barrier; requires knowledge of implementation

internals

• LTac– untyped tactics, somewhat limited programming model

• Proof-by-reflection– strong static guarantees but very limited programming model

VeriML enables all points between no static guarantees to strong ones, yet with full ML programming model

Automated program verifiers & tools

• Build certified program verifiers for each DSL– some are decidable

• Develop new VeriML tactics – certifying compiler, linker, assembler

– static analysis

– decision procedures (e.g., Omega, SMT solvers)

• Connecting with first-order theorem provers– let them generate hints or witnesses

– add an additional validation phase to build the proof objects

• Better proof witness: type-safe VeriML proof scripts

010110101010101011111000110011101101111111010101010101010101010101111111110101010101011110001100010101010101010111111000110010011110011111111001111111000111100010101010111111011100

110011101010101111111000111100

Application & other system SW

Conclusions

Formal specs & proofs for resilience,

extensibility, security?

HW & Env Model

Key innovations:

• new OS kernel that can “crash-proof” the entire SW

• new PLs for writing certified kernel plug-ins (new OCAP + DSLs)

• new formal methods for automating proofs & specs (VeriML)

ResourceManagers

ProtectedExecutors

DeviceDrivers

Certified Kernel

CPU CPU GPU GPU Disk NIC

NativeExecutor

TypesafeExecutor

VMMExecutor

SFIExecutor

Scheduler Scheduler

Driver Driver

FS Net

DriverDriver

LegacyX86App

Java/MSILApp

NaClApp

LegacyOS + App

Advanced Development of Certified OS Kernels Prof. Zhong Shao (PI) & Prof. Bryan Ford (Co-PI), Yale University

A crash-proof computing host needs to have a certified OS kernel to serve as its bedrock.

MAIN OBJECTIVE:To develop a novel certified OS kernel that offer (1) safe & application-specific extensibility, (2) provable security properties with information flow control, and (3) accountability & recovery from hardware or application failures.

KEY INNOVATIONS: • Secure & flexible kernel via certified plug-ins• History-based accountability & recovery mechanism• Provably correct security monitor for IFC• A new DSL-centric open framework for certified

decomposition & programming & linking• New DSLs/history-logic for certifying kernel

modules• Novel VeriML language & tools that can combine

automation with modular proofs

Components in traditional OS kernels can interfere with each other in arbitrary way.• A single kernel bug can wreck the entire system’s integrity & protection• Poor support for recovery & security

Synergistic co-development effort combining novel advances in OS, prog lang & env, and formal methods•New VeriML/OCAP programming evironment for building certified system software

EXPE

CTED

IMPA

CTOT

HER

UNIQ

UE A

SPEC

TS

PROPOSED ACHIEVEMENT

STAT

US Q

UONE

W IN

SIGH

TS

ResourceManagers

ProtectedExecutors

DeviceDrivers

Certified Kernel

CPU CPU GPU GPU Disk NIC

NativeExecutor

TypesafeExecutor

VMMExecutor

SFIExecutor

Scheduler Scheduler

Driver Driver

FS Net

DriverDriver

LegacyX86App

Java/MSILApp

NaClApp

LegacyOS + App

Only a limited set of features at certain abstraction layer are used in specific kernel modules• Structure the kernel using certified abstraction layers will minimize unwanted interferences & maximize modularity and extensibility

• Machine-checkable formal guarantees about OS kernel safety and security• Reliable crash recovery & accountability mechanisms• A solid base for building adaptive immunity mechanisms• A new programming paradigm for building certified bug-free software