a temporal logic for calls and returns p. madhusudan university of pennsylvania joint work with...

32
A temporal logic for calls and returns P. Madhusudan University of Pennsylvania Joint work with Rajeev Alur and Kousha Etessami Talk at HCES 2004, Philadelphia

Post on 21-Dec-2015

214 views

Category:

Documents


0 download

TRANSCRIPT

A temporal logic for calls and returns

P. MadhusudanUniversity of Pennsylvania

Joint work with

Rajeev Alur and Kousha Etessami

Talk at HCES 2004, Philadelphia

Overview

Context: Software model checking

Paradigm: Abstract program into a boolean pushdown model Check if model satisfies the specification

Main Contribution:

• A temporal logic (CARET) that can express useful properties of software that cannot be expressed by LTL/automata.

• CARET formulas express context-free properties

• Pushdown models can be model-checked against CARET. Moreover, Complexity of checking CARET is same as Complexity of checking LTL

Model Checking

Formally model the systemModel is an abstraction of the systemModel is less complex

Formal specification Temporal logics (LTL [Pnu76], CTL [CES81]),

Automata Algorithmically verify whether model satisfies the

specification

SystemVerifier

ModelAbstractor

Correctness specification

Yes!

No(Counterexample)

Abstracting Software

int x, y;

if x>0 { ……. y:=x+1 .……}else { …… y:=x+1 ……}

bx: x>0

by: y>0

Program

bool bx, by;

if bx {

………

by :=true

………}else { …………

by :={true,false}

……….}

Boolean Program

Boolean programs

Boolean programs are hence finite state transition systems

Entry points

Exit points

bool bx, by;

if bx {

………

by :=true

………}else { …………

by :={true,false}

……….}

Boolean Program

Abstracting Modular Programs

main() { bool y; … x = P(y); … z = P(x); …}bool P(u: bool) {…return Q(u);}bool Q(w: bool) { if … else return P(~w)}

A2

A1

A3

A2

A2

A3

A3

A1Entry-point

Exit-point

Box (superstate)

Program Recursive State Machine (RSM)/ Pushdown automaton

Abstracting Modular Programs

main() { bool y; … x = P(y); … z = P(x); …}bool P(u: bool) {…return Q(u);}bool Q(w: bool) { if … else return P(~w)}

A2

A1

A3

A2

A2

A3

A3

A1Entry-point

Exit-point

Box (superstate)

Program Recursive State Machine (RSM)/ Pushdown automaton

Nice graphicalrepresentationof pushdownmodels!

Algorithms can work on this graphdirectly.

Abstracting modular programs

To model control flow, we need to model the call stack Models of programs are hence pushdown transition systems

Algorithms exist for checking regular specifications against pushdown models [BS92,BEM97] Convert specification into a regular language ----> get L Complement the (regular) specification L ----> get L Intersection of a regular language and a context-free language is

context-free: let L’’ = LM L

Emptiness of pushdown automata is solvable:

check if L’’ = L’’= iff model M satisfies specification

In practice, “summary” procedures are used: Eg. SLAM (Microsoft Res.)

L

LTL

Linear-time Temporal Logic (LTL) over Prop: Q ::- p | not Q | Q or Q’ | Next Q |

Always Q | Eventually Q | Q Until Q’

Interpreted over (infinite) sequences:

X0 X1 X2 X3 X4 … … … where each Xi .Prop

Useful for stating sequencing properties: If req happens, then req holds until it is granted: Always ( req → (req Until grant) )

For any formula Q, Models(Q) is a regular language.

LTL is not expressive enough

LTL cannot express:

Classical Hoare-style pre/post conditions If p holds when procedure A is invoked, q holds upon

return Total correctness: every invocation of A terminates Integral part of emerging standard JML

Stack inspection properties For security/access control

If a variable x is being accessed, procedure A must be in the call stack

Above requires matching of calls with returns, orfinding unmatched calls --- Context-free properties!

Context-free specifications

But model-checking context-free properties against context-free models is Undecidable. (Inclusion of CFLs is undecidable)

However, the properties described are verifiable.

Existing work in security that handles some stack inspection properties [JMT99, JKS03]

Question: Define a logic that can state the above properties and is yet model-checkable against pushdown models.

CARET

CARET: A temporal logic for Calls and Returns Expresses context-free properties

A

B

C

A

Global successor used by LTL

………….

CARET

CARET: A temporal logic for Calls and Returns Expresses context-free properties

A

B

C

A

Global successor used by LTL

………….

Abstract successor: Jump from calls to returns Otherwise global successor at the same level

CARET

CARET: A temporal logic for Calls and Returns Expresses context-free properties

A

B

C

A

Global successor used by LTL

………….

Abstract successor: Jump from calls to returns Otherwise global successor at the same level

CARET

CARET: A temporal logic for Calls and Returns Expresses context-free properties

A

B

C

A

Global successor used by LTL

………….

Abstract successor: Jump from calls to returns Otherwise global successor at the same level

Abstract path

CARET

CARET: A temporal logic for Calls and Returns Expresses context-free properties

A

B

C

A

Global successor used by LTL

………….

Abstract successor: Jump from calls to returns Otherwise global successor at the same level

Caller modality: Jump to the caller of the current module Defined for every node except top-level nodes

CARET

CARET: A temporal logic for Calls and Returns Expresses context-free properties

A

B

C

A

Global successor used by LTL

………….

Abstract successor: Jump from calls to returns Otherwise global successor at the same level

Caller modality: Jump to the caller of the current module Defined for every node except top-level nodes

Caller path gives the stack content!

CARET Definition

Syntax: Q ::- p | not Q | Q or Q’ | Next Q |

Always Q | Eventually Q | Q Until Q’

Abs-Next Q | Abs-always Q Abs-Eventually Q | Q Abs-Until Q’

Caller Q | Callerpath-always Q CallerPath-Eventually Q | Q CallerPath-Until Q’

Abstract- and Caller- versions of all temporal operators All these operators can be nested

Expressing properties in Caret

Pre-post conditions If P holds when A is called, then Q must hold when

the call returns

Always ( (P and call-to-A) Abstract-Next Q )

A

PQ

Pre-post conditions are integral to specifications for JML (Java Modeling Language)

Expressing properties in Caret

All calls to A return

Always ( call-to-A Abstract-Next true )

A

Expressing properties in Caret

If A is called with low priority, then it cannot access the file Always ( call-to-A and low-priority

Abstract-Always ( not access-file ) )

Alowpriority

Ahighpriority access-file

Expressing properties in Caret

Stack inspection properties

If variable x is accessed, then A must be on the call stack Always ( access-to-x

CallerPath-Eventually A )

access-to-x

A

Also, CARET can express data-flow analysisproperties

Model checking CARET

Given: A (boolean) recursive state machine/ pushdown automaton M A CARET formula Q Model-checking: Do all runs of M satisfy the specification Q?

CARET can be model-checked in time that is polynomial in M and exponential in Q.

|M|3 . 2O(|Q|)

In fact in time |M|. θ2 . 2O(|Q|)

where θ = max number of entries/exits Complexity same as that for LTL !

Model checking CARET

Given: Pushdown model M and CARET formula Q

Build a Büchi pushdown automaton A:

States: (s, T) where s is a state of the model T is a subset of “FL-closure” of subformulas of Q

A accepts a word w iff

w is a behaviour of M and w does not satisfy Q

Model-checking CARET: intuition

Main Idea: The specification matches calls and returns of the program. Hence the push (pop) operations of the model and the

specifications synchronize

Handling Abs-Next formulas

s, Q1

sPush s and Q1

Abs-Next Q1 Pop s and Q1 ;

Check Q1

Model-checking CARET: intuition

Handling Caller formulas: Keep track of which caller formulas are true.

s, Caller Q1

Caller Q1

Q1

Abs-Next Q1

s

Caller Q1

Can similarly handle Caller-path until formulas

Model-checking CARET: intuition

Handling Abs-Until formulas:

There can be infinitely many abstract paths.Signalling Buchi sets cannot be done for all these paths as they satisfy different Until-formulas

However, there is only one infinite abstract path in any run.Automaton will guess this infinite path and use Buchi final states to signal acceptance on this path.On finite abstract paths, Buchi condition is not needed.

Future work that’s done already!

Generalizing the idea: M and L are context-free. Checking if M is a subset of L is decidable.

So, what is going on?

Intuition: M and L are synchronizing on stack operations.

Can we generalize this idea? LTL Regular languages CARET ???

Generalizing the idea (to appear in STOC ’04)

Structured words: Partitioned alphabet:

Σ = Spush Spop Sinternal

Consider finite words over Σ

A visibly pushdown automaton over Σ is a pushdown automaton that pushes a symbol onto the stack on a letter in Spush

pops the stack on a letter in Spop

cannot change the stack on a letter in Sinternal

Note: Stack size at any time is determined by the input wordbut not the stack content

A language is a VPL over a partitioned alphabet Σ, if there is a visibly pushdown automata that accepts it (acceptance by final state)

CARET is contained in VPLModel-checking:

CARET Q VPL LQ

Pushdown model M VPL LM

M satisfies Q iff LM LQ = (Emptiness of pushdown automata is decidable)

Visibly pushdown languages (VPL)

VPL is closed under boolean operations: union, intersection and complement

Conclusions

CARET: logic of context free specificationsSpecification logic for expressing interesting

properties of software: pre-post conditions, stack-inspection, etc.

Model-checking CARET is not more expensive than LTL.Checkable in time |M|3 . 2O(|Q|)

Also, existing model-checking algorithms can be extended easily

to verify CARET.

Future work

Build a tool for model-checking CARET (should be simple!)

How robust is CARET? Are there more useful operators that can be handled easily? Conjecture: CARET captures all FO-definable properties of VPLs?

Can one solve games for CARET specifications? (ongoing work)