Self-Stabilization as a Foundation for Autonomic Computing Olga Brukman, Shlomi Dolev, Yinnon A. Haviv, Reuven Yagel. Ben-Gurion University of the Negev,

Self-Stabilization as a Foundation for

Autonomic Computing Olga Brukman, Shlomi Dolev,Yinnon A. Haviv, Reuven Yagel.

Ben-Gurion University of the Negev,Beer-Sheva, Israel

FOFDC 2007, Vienna

FOFDC 2007, Vienna

Trends in Autonomic Computing Self-healing, Self-managing, Self-*. Recovery Oriented Computing [Berkeley,

Stanford]. Autonomic Computing [IBM]. Robust infrastructure for achieving the above is

missing. Processor. Operating systems do not stabilize. Nothing built on top of this platform can be fully

robust.

FOFDC 2007, Vienna

Self-Stabilization: Well Established Theory !

Self-Stabilization[Dijk’74]. Self-Stabilization [Dolev’2K]. Abstract, stand-alone

algorithms. Self-stabilization was not

fully deployed in real-life systems. Self-stabilizing protocols.

Routing Information Protocol (RIP).

FOFDC 2007, Vienna

Self-Stabilization

Self-stabilization is achieved through algorithm fully exploring the system state space.

Self-stabilizing algorithm is continuously executed, and its code is not corrupted.

FOFDC 2007, Vienna

Self-Stabilization as a Base for True Autonomic Computing

Well defined and provable property. Ability to deal with unpredicted

failures. Automatic recovery from any state.

FOFDC 2007, Vienna

Self-Stabilization Stack

Self-Stabilizing Program

Stabilization Preserving Compiler

Self-Stabilizing Operating System

Self-Stabilizing Processor

FOFDC 2007, Vienna

Self-Stabilization Stack: Non Self-Stabilizing Programs

Self-Stabilizing Operating System

Self-Stabilizing Processor Recovery Oriented Program

Self-Stabilizing Automatic Recoverer

Eventually Byzantine Program

Self-Stabilizing ProgramRecovery Oriented

SoftwareStabilization Preserving Compiler

Self-Stabilizing Processor

Shlomi Dolev, Yinnon A. Haviv

FOFDC 2007, Vienna

Self Stabilizing Microprocessor

Legal execution of a processorEvery process starting from an arbitrary state

reaches fetch-decode-execute sequence. What is a self-stabilizing processor?

Every execution of the processor starting from an arbitrary state reaches a safe configuration, which implies legal execution after the safe state

FOFDC 2007, Vienna

Self-Stabilizing Processor: How?

Verifying self-stabilization in existing processorEach circle in the processor automata

has a fetch-decode-execute loop. Adding self-stabilization to a

processorUsing a self-stabilizing watchdog

Self-Stabilizing Operating System

Shlomi Dolev, Reuven Yagel

FOFDC 2007, Vienna

Self-Stabilizing Operating System

Black boxReloading OS code from ROM periodically.The reloading function is hardwired in ROM

Tailored SolutionProcess schedulingMemory managementDevice drivers

FOFDC 2007, Vienna

Tailored Solution: Scheduling

Fairness and stabilization preservation Periodic execution

non-maskable interrupts and watchdog Scheduler state (process table)

correctnessBounded index to fix number of processesEnforcing separation through segmentation

FOFDC 2007, Vienna

Tailored Solution: Memory Management

Eventual consistency of memory hierarchy Stabilization preservation

Processes do not affect other processes memory

SolutionsAllocate entire memory Fixed partitions with continuous monitoringLease based dynamic schemes

FOFDC 2007, Vienna

I/O Device

Tailored Solution: Device Drivers

OS

DeviceDriver

Ping-pong requirement Exchange requests and replies infinitely often

Progress requirement Eventually every I/O request is executed according to

specifications

Self-stabilizingprotocol

Controller

FOFDC 2007, Vienna

Tailored Solution: Device Drivers Self-stabilizing protocol

1. Lease based execution of the protocol

OR

2. Assuming the device controller is self-stabilizing, enforces state consistency through snapshots.

FOFDC 2007, Vienna

Tailored Solution: Implementation

Prototype based on Intel Pentium processor

Detailed proof of the assembly code correctness

Our prototype shows that it is possible to design a self-stabilizing OS kernel.

Self-Stabilization Preserving Compiler

Shlomi Dolev, Yinnon A. Haviv,

Mooly Sagiv,Department of Computer Science

Tel Aviv University, Israel

FOFDC 2007, Vienna

Non-Stabilization Preserving Compiler

S and T behave the same only when started in the initial state.

Existing compilers are non-stabilization preserving T may reach an unexpected state due to soft-error

experienced by microprocessor

CompilerS

high abstraction language

Tmachine language

FOFDC 2007, Vienna

Non-Stabilization Preserving Compiler: Example

Compiled code: start with cx=12 inside the loop… Moreover: Any runtime mechanism can get stuck or

become inconsistent. Stack, heap

mov ax, 10 mov cx, 0loop1: push cx call f inc cx cmp cx,ax jne loop

for (int i=0; i<10; i++) f(i)

FOFDC 2007, Vienna

Stabilization Preserving Compiler

upon <condition_1> do

<statement_1>

Variable declarations

upon <condition_n> do

<statement_n>

S.P. Compiler

Enforce invariants

Scheduler

condition_1

…

condition_n

Statement_1

Statement_n

Recovery Oriented Software

Olga Brukman, Shlomi Dolev

FOFDC 2007, Vienna

Software Contains Bugs

Writing self-stabilizing software is hard Correct and faultless SW is hard

Long-lived running programs, e.g., OSHeisenbugs, corrupt states, leaked resources

are common… Usually software is tested when starting

from initial state and considering limited time scenarios.

FOFDC 2007, Vienna

Fault Model Reflecting Reality Software packages can be trusted to work as

required after restart. Eventual Byzantine software. System administrators and users use reboot to

deal with faults. Contract between the client, project manager and

programmers, that is checked on line! Additional (thin) monitoring and recovering layer

is self-stabilizing.

FOFDC 2007, Vienna 26

Parts in Contract

Specifications Composer (Project Manager) Invariants and predicates

important properties on program IO

Recovery actions

• Programmer• Best-effort implementation

• Using same IO variables as specifier

• Still: bugs and unexpected states

FOFDC 2007, Vienna

Environment

Long enough to do sufficient job

Self-stabilizing processor + Self-stabilizing OS Processes exist and execute their code Infrastructure for robust monitoring and recovery

Not immediately Byzantine eventual Byzantine program

Self-Stabilizing Recoverer for Eventual

Byzantine Software

Olga Brukman, Shlomi Dolev

Hillel Kolodner,Haifa Research Labs

IBM, Israel

FOFDC 2007, Vienna

Middleware Architecture

OS

Kern

el

OMR

<Preds,RActs>1

<Preds,RActs>2

…<Preds,RActs>n

<Preds,RActs>

<Preds,RActs><Preds,R

Acts>

<Preds,RActs>

<Preds,RActs>

Recovery Oriented Programming

Olga Brukman and Shlomi Dolev

FOFDC 2007, Vienna 31

Our Framework: Transforming Recovery Tuples into Code

Code

Recovery tuples

Subsystemshierarchy

event-driven monitoring

event-driven monitoring

External Monitor

SubsystemExternal Monitor

Pre-compiler

event-driven monitoring

event-driven monitoring

External Monitor

event-driven monitoring

event-driven monitoring

External Monitor

FOFDC 2007, Vienna

Conclusions Self-Stabilization as an effective paradigm

for creating robust systems. Rigorous approach for designing basic

system componentsMicroprocessorOperating systemCompilerRecovery Oriented Software

FOFDC 2007, Vienna

Stabilization Preserving Compiler [DHS05]

Self-Stabilizing Operating System [DY04]

Self-Stabilizing Processor ]DH06[

Recovery OrientedSoftware [BDK03, BD06]

Faces Behind the Paper

Thank You!Questions?