1 A Formal Monitoring-based Framework for Software Development and Analysis Feng Chen Marcelo...

1

A Formal Monitoring-based Framework for Software Development and Analysis

Feng ChenMarcelo D'AmorimGrigore Rosu

University of Illinois at Urbana-Champaign

2

Motivation :Increase Software Reliability

Traditional formal verification methodsHigh confidence, do not always scale up well

TestingScalable, but adhoc, no correctness guarantees

What do we really want … ?A.Prove a program correct?B.Correct execution!

A => B … but isn’t the price too big?

3

Overview

• Monitoring Software Systems

• Monitoring-Oriented Programming (MOP)

• Java-MOP

• An HTTP-Server Example

• Conclusion and Future Work

4

Avoiding Complexity whileEnsuring Safety by Monitoring

(Example by Lui Sha - Simplex)

Joe is a student in an algorithms classFinal exam is to develop a sorting algorithm

If incorrect then Joe fails the classIf provably correct but inefficient then he gets BIf both correct and efficient then he gets A

Hm, heap sort is efficient but hard to prove correct; insertion sort is trivial to prove correct but it is not efficient

Hm, heap sort is efficient but hard to prove correct; insertion sort is trivial to prove correct but it is not efficient

5

Joe’s Solution

Heapsort

O(n log(n))

Monitor ifvector issorted

yes

O(n)

Insertionsort

no

O(n2)provablycorrect

Joe has an efficient and provably correct sorting algorithm!He avoided proving heap sort correct, which is hard!

6

Monitoring in Engineering

Most engineering disciplines take monitoring

as basic design principleFire alarms in buildings

Fuses in electronics

Watchdogs in hardware

Why not to do the same in software eng.?Monitoring-oriented programming

7

Monitoring-Oriented Programming (MOP)Proposed at RV 2003

Monitoring already used in software developmentDesign By Contract, Runtime Verification (MaC, PaX, …)

MOP underlying motivations and challenges• Can one generically and formally capture the vario

us approaches to monitoring and runtime verification in a unified manner?

• Monitoring should be a design and software development principle. Write programs having monitoring in mind!

8

What are the foundational principles of monitoring programs?

Program

S1 S2 . . . . . Sn

1. Observation

Specification

2. Checking

3. Recovery

9

Goal of MOP

The different approaches to RV rely on implicit,carefully chosen instance of the 3 principles

1. Observation2. Checking3. Recovery

MOP aims at separation and individual advancementof the three principles

Three ways to look at MOP1. Merging specification and implementation2. Extending languages with logic-based statements3. A light weighted formal method

10

MoP Example: A traffic light monitor

Following monitor can appear in a Java program.../*@ logic=FTLTL { predicate red = tlc.state.getColor() == 1; predicate green = tlc.state.getColor() == 2; predicate yellow = tlc.state.getColor() == 3; formula : []( green -> (! red U yellow)); Violation handler : … any code}@*/...

It is pre-compiled into actual Java code...switch(bttFsmState) {

case -1 : break; case 1 : bttFsmState = tlc.state.getColor()==3 ? 1 : tlc.state.getColor()==2 ?

tlc.state.getColor()==1 ? 0 : 2 : 1; break;

case 2 : bttFsmState = tlc.state.getColor()==3 ? 1 : tlc.state.getColor()==1 ? 0 : 2;

break; }

if(bttFsmState == 0) { … the “recovery” code …}}

...

11

MoP Features andDesign Principles

12

Extending Languages with Logics

• Do not modify host languages– Able to reuse heritage systems– Evolve with languages and compilers

• Specifications can be – Annotations in the source code

• Especially for checkpoints

– In separated specification files• Separation of concerns• Improved reusability

13

MOP Specification Syntax

/************** Heading starts ****************/[attribute]* <Type> <Name> logic= <Logic Name> {

/************* Body starts ********************/

... Specification Body ...

/************* Handler starts *****************/[Violation Handler: ...handling the violation...]

[Validation Hander: ...handling the validated...]

}

class-inv logic = ERE {

var int flag = -1;event suspend: called(void suspend()) {flag = 1;};event resume: called(void resume()) {flag = 2;};formula: (suspend resume)*

Violation Handler: if (flag == 2) { System.out.println("resume() called before suspend() in HttpClient! Adding client back to queue ..."); synchronized(suspendedClients){ suspendedClients.add(thisObject); } } else { System.out.println("suspend() called twice before resume() in HttpClient!"); }}

DefinitionExample

14

MOP Specification Syntax

• Attributes– static, inline/outline, sync/async

• Types of specifications:– class invariants, interface constraints, method

pre-post conditions, checkpoints.

• User-defined handlers– Violation and/or validation handlers

• Not all combinations always possible

15

Sorting Example

method (HeapSort(int[] a)) logic=JML {

ensures isOrdered(a);

Violation handler: InsertionSort(a);}

…

if (! isOrdered(a)){ InsertionSort(a);}

…

16

Security Example

class-inv logic=ERE {

event auth = authentication();event use = accessResource();formula: (! auth)* use;

Validation handler: authentication();}

switch ($state) { case 0 : $state = use ? 1 : ! auth ? 0 : -1; break; }

if ($state == 1) authentication();

17

Extensible Logic Framework

18

Workflow of MOP

19

Logic Plug-ins

• No silver-bullet logic to express any requirements• To add a new MOP requirements formalism, all on

e needs to do is to provide a logic plug-in– Logic plug-in consists of a language shell and a logic en

gine; several logic plug-ins can share a logic engine

• The I/O of the logic plug-in is standardized to facilitate extensibility

• Logic plug-in encodes a monitor synthesis algorithm: formula -> monitor

• WWW repository of logic plug-insfsl.cs.uiuc.edu/mop

20

Current Logic plug-ins

• Linear Temporal Logic (LTL)– Past Time LTL– Future Time LTL

• Extended Regular Expressions (ERE)• Design By Contract: Jass, JML (partly)• To be supported:

– RTL, MTL, …– Users can easily add new logics via provided standar

dized interface

21

Future time LTL plug-in

Input:[] (green -> (! red) U yellow)

Output:Declaration. int state;Initialization. state = 1;Monitoring Body. switch (state) { case 1 : state = yellow ? 1 : green ? (red ? -1 : 2) : 1; case 2 : state = yellow ? 1 : red ? -1 : 2; }Failure Condition. state == -1

Algorithm jointly with Havelund(RV’01)

Algorithm jointly with Havelund(RV’01)

22

Past time LTL plug-in

Input:start(P) -> [Q, end(R \/ S))

Output:Declaration. boolean now[3], pre[3]Initialization. now[3] = R || S; now[2] = Q; now[1] = P;Monitoring Body. now[3] = R || S; now[2] = (pre[2] || Q) && (now[3] || (! pre[3])); now[1] = P;Failure Condition. now[1] && (! pre[1]) && (! now[2])

Algorithm jointly with Havelund(TACAS’02)

Algorithm jointly with Havelund(TACAS’02)

23

Extended RE plug-in

Input:~((~ empty)(green red)(~ empty))

Output:Declaration. int state;Initialization. state = 0;Monitoring Body. switch (state){ case 0 : state = (yellow || red) ? 0 : green? 1 : -1; case 1 : state = green ? 1 : yellow ? 0 : -1; }Failure Condition. state == -1

Algorithm jointly with Sen (RV’03)

Algorithm jointly with Sen (RV’03)

24

Java-MOP

A prototype supporting part of the desired MOP features in Java

25

Java-MOP Overview

• Provides GUI and command-line interfaces– Online interface: http://fsl.cs.uiuc.edu/mop

• Supports FTLTL, PTLTL, ERE, Jass, JML

• Uses AspectJ for monitor integration– Limitations

• Can only monitor scalar fields of classes for class invariants

• The event generation and analysis are not atomic

26

Java-MOP Architecture

27

Java-MOP at Work

A buggy HTTP server

- taken from an IBM repository of buggy concurrent Java programs

28

29

Request access to the server

Granted?

work Put itself into the waiting queue

Get a client from the waiting queue, and resume it

suspend itself

Exit

Yes No

1

23

30

2 suspend2

Clienti Clientj

Exit

suspend

Has been removed from

the waiting queue!

SuspendedClients

Clienti

1

3Stopped

add

remove & resume

31

A bad trace

32

The Bug

• Caused by “unexpected” thread interleaving– Not easy to analyze and test

• Root cause– Violation of the basic assumption for suspend()

and resume(): (suspend() resume())*

• Can we fix it on-the-fly in case of violation?• Yes: put the client back into the queue to

allow another client to resume it later.

33

34

Trace with Monitor

35

Conclusion and Future Work

• MOP: a uniform logic-independent monitoring framework.

• Java-MOP: a prototype for Java

• Incorporate more logics/paradigms, especially those that are widely accepted– Complete JML, RTL, MTL, …– WWW repository of logic plug-ins

• Turn Java-MOP into a mature tool– Currently a prototype– Use it on real and large applications

• Support more programming languages