specification and verification of aspects shmuel katz

Specification and Verification of Aspects

Shmuel Katz

Topics

Background on general software specification and verification Possible approaches, temporal logic,

model checking, existing tools Specifications of aspects Model checking for aspects—one

approach

Specifications for programs: What do we want?

NOT a complete description of everything true of the program

Desired properties of the program To enable tool-based analysis, should

be expressed in a precise notation Often in assume-guarantee form: If the assumption is true when the

module executes, it fulfills the guaranteed property

Simple assume-guarantee Assumption: input values are nonnegative Guarantee: result is the sum of the inputs

Assumption: input array has no repeats Guarantee: the array is sorted

Note: using logic can be misleading: 1≤ i ≤ n. a[i] < a[i+1] is not enough for sorting

Simple assume-guarantee (cont)

Assertions are about the system state when the module begins (assumption) and the system state when it ends (guarantee)

Logical assertion defines a set of states Written as {P} S {Q} (Hoare logic) Insufficient for ongoing properties

Mutual exclusion of critical sections Fair scheduling Each message is answered

Propositional temporal logic

AP – a set of atomic propositionsTemporal operators:GpFpXppUq Path quantifiers: A for all path E there exists a path

Aspect Specification

Aspects also have an assume-guarantee specification

Requirements about base systemResults to hold in augmented system

For any base system satisfying the requirements, the augmented system with this aspect will satisfy the results. Both can be general temporal logic assertions.

Examples (1): Password Encoding

Assume: all messages with passwords are from the user to the system, from some kind of login page (first time, regular, change pwd,…)

Guarantee: All messages with passwords are encoded before sending, and decoded at the other end…+ no other effect…

Examples(2): Extending graphic displays

Assume: Whenever there is a display-req when no display is being shown, eventually an updated display is shown

Guarantee: Whenever there is a display-req, eventually an updated display will be shown

Examples(3): Authorization

Assume: Operations a,b, and c can be executed by anyone

Guarantee: Only users of type X can execute operations a or b; c is still executable by anyone.

Also, the operations themselves are unchanged.

Aspect Verification: What do we want?

Advice: state machine APointcut: descriptor ρSpecification:

Base machine requirement PWoven machine result QP and Q are LTL

Interpreting the specification

Correctness assertion of an aspect:

For all base machines BIf “B satisfies P”Then “B woven with A according to ρ satisfies Q”

Recall: P and Q are general LTL formulas, not just state assertions

Aspect Verification

Aspect red requires blue

and guarantees orange

Why this approach? Modularity

Consider the aspect independently from the base machine

Prove red guarantees orange

Prove base is blue

Why (2)? Genericity

Consider the aspect independently from any base machine

Prove red guarantees orange

Prove base or base or base is blue

Other Work

Checking the augmented systemNot modularCan do generic set-up using aspects to annotate augmented systemSihman and Katz

Extending CTL propertiesGiven a particular base systemKrishnamurthi, Fisler, & Greenberg

Here: once-and-for-all the aspect satisfies its specification

Checking aspect without a base

Cheap and general

Arbitrary LTL properties for both the requirements and the results

Any base system

M=<S, I, R, L>

• S - Set of states. • I S - Initial states.• R S x S - Total transition relation.• L: S 2AP - Labeling function.

AP – Set of atomic propositions

An abstraction of a Program: Model of a system

Model of a system Kripke structure, State Machine

a,b a

ab,c

c

a,c a,bb

Another State Machine

Fairness

Problem with nondeterminism: often allows the system to “do nothing” foreverImpose a fairness constraint, and only look at fair pathsFairness set F: set of subsets of S

A path is fair iff it visits every set in F infinitely often

Fairness

X

Paths as sequences of states

A sequence of states =s0s1s2... is a path in M from s iff

s = s0 and for every i0: (si,si+1)R

What is model checking? Given a finite representation of a model

(a program), and an assertion about execution paths in temporal logic, check whether the assertion holds for every possible execution path (even infinite ones!) and thus is a property of the model

Generate compact representations, use clever algorithms to check, restrict assertion language, use abstractions and reductions to get smaller models, …

Linear temporal Logic (LTL)

Temporal operators, but no path quantifiers except an implicit A at the outermost level

Claims that every path satisfies the LTL formula. Checked by building an automaton representing

the formula (a tableau), making a cross product of the negation of the automaton with the model, and checking for emptiness (=success).

Nonemptiness is shown by a computation that is actually a counterexample to the formula.

Tableau

G a

Tableau

F b

Computation Tree Logic(CTL) [not used here]

CTL operator:path quantifier + temporal

operator

Atomic propositions: pAPBoolean operators: f g , f g

AX f, A(f U g), AG f , AF fEX f, E(fUg), EG f , EF f

Symbolic model checking [not used here] Compute all at once the set of states

satisfying Q pred(S) the predecessors of a set S succ(S) the successors of a set S

Use Binary Decision Diagrams to compute those sets efficiently.

Have especially efficient algorithms for CTL assertions over Kripke structures

Binary decision diagrams (BDDs) [Bryant 86] [not used here]

Data structure for representing Boolean functions

Often concise in memory Canonical representation Boolean operations on BDDs can

be done in polynomial time in the BDD size

Software model checking Tool that allows annotating (Java) code,

abstracting domains, expressing properties to be checked

Bandera (or others) generate input to existing tools like SMV, Spin, …

For proper abstractions, success means the checked property holds for every execution

Often ends with a counter-example Can fail due to state explosion, giving no info Algorithmic (except for finding abstractions)

Model checking (without aspects) is becoming popular

Widely used for hardware designs (Intel, IBM)

Fairly common for safety-critical protocols Air-traffic control and railway routing Control of nuclear reactor rods

Increasing use for general software Java pathfinder from NASA SLAM model checker from Microsoft, to check

software driver programs, extended to SDV Better than testing at discovering bugs

Problems with Model Checking

Data manipulations cause state explosion

Asynchronous processes cause state expl.

New Objects mean “expanding state” High-level operations may represent

many steps (Method calls, synchronizations, wait)

Strategy

Build a “generic” state machine version of assumption PWeave the aspect into this modelProve that this augmented generic model satisfies the desired resultTψTP Tψ

State Machines (Reminder)

Finite set of states SSet of atomic propositions APLabeling function L : S → 2AP

Path relation R containing pairs (s,t) when there is a transition from s to tFairness set (states that must be visited infinitely often)

LTL Formulas (Reminder)

A F cA F G ¬bA G ((¬a Λ b) → F a)

Base Machine

State machine BComputation starts from one of the initial states S0 S

Base Machine

S0

Advice

State machine AInitial states S0

Return states Sret

S0 Sret

Pointcuts

Pointcut descriptor ρMatches the end of a pathPast LTL, regular expressions, ...

Pointcut

ρ = a Λ Y b Λ Y Y b

? ? ?

Components for modular model checking of aspects

State machinesFairnessLTLBase machinesAspect advice machinesAspect pointcuts

Weaving

Inputs:Base machine BAspect machine APointcut ρ

Output:Woven machine B ̃

Problem: a state could have some

paths reaching it that are pointcuts, and others that are not

Weaving A with B

Step 1: Make B pointcut-ready for ρResult: Machine Bρ

Step 2: Augment Bρ with A

Result: Augmented machine B ̃

1. Pointcut-Ready

Unwinding of paths such that each state either definitely does or definitely does not match the pointcutMatching states are labeled ‘pointcut’Done on the base machine, before weavingHas the same collection of paths (so LTL assertions are unchanged)

1. Pointcut-Ready

Advantage: simplicityDisadvantage: doesn’t handle all situations (especially pointcuts inside aspect states, or when aspects invalidate pointcuts in base)

No problems for many aspectsState pointcutMethod call pointcut

1. Pointcut-Ready

ρ = a Λ Y b Λ Y Y b

2. Augmenting

Transitions from base machine ‘pointcut’ states to aspect initial statesTransitions from aspect return states to base machine statesAccording to state labels

2. Augmented

Rule: add all edges‘pointcut’ → aspect initialaspect return → base

Where the labels exactly matchRemove other edges from pointcut states

Problem

What if the aspect puts the base program into a state it could never reach on its own?The behavior of the base program from that point is unknown (and not restricted by P)

Weakly Invasive: Reminder

Aspect returns to the base program only in states reachable by that base program on its own

SpectativeRegulativeInvasive within original domain

Weakly Invasive

Aspect returns to the base program only in states reachable by that base program on its own

Many, if not most, “classic” aspects are weakly invasive (logging, authorization, discount policy, reducing fractions,…)

(New) Correctness Assertion

ProveFor all base machines BIf “B satisfies P”And “A with ρ is weakly invasive for B”Then “B woven with A according to ρ satisfies Q”

Weakly Invasive

All edges from aspect return states go to reachable states in the base machine

Tableau

A “generic” model built from the assumption formula P

TP

Exactly all the paths which satisfy a given LTL path formula

TP

Tableau

G a

Tableau

F b

Tableaux

For a given LTL formula PIf a path supports the formula, it must be in the tableau

For any machine satisfying PAll its paths must be in the tableau

Recall

Advice: state machine APointcut: descriptor ρSpecification:

Base machine requirement PWoven machine result Q

A, ρ, P, and Q over AP

Step 0

Throw all the atomic propositions in AP into P, in clauses of the form

⋯ Λ (a ¬a)

Step 1

Construct TP, the tableau for P

TPTP

Step 2

Restrict TP to its reachable component

Step 3

Weave A into TP according to ρ

Result: T ͠P

T ͠P

If can’t reconnect—aspect is not weakly invasive

Tψ

Step 4

Determine if T ͠P |= Q

orangeTψ

Claim

If T ͠P |= QThen for any B

If B |= PAnd A and ρ are weakly invasive for B

Then B̃ |= Q

Proof Outline

TP has every possible path satisfying P

So TP͠ has every possible augmented

pathB satisfies P, so every path of B corresponds to a path through TP

If T ͠P |= QThen every possible augmented path of B͠ supports Q

Aspect example

P = A G ((¬a Λ b) → F a) (Requirement)Q = A G ((a Λ b) → X F a) (Result)ρ = a Λ b (Pointcut)A =

TP for AG((¬a Λ b) → Fa)(g = Fa)

TP

T ͠P Tψ

T ͠P |=AG((aΛb)→ XFa) Tψ

Result

The aspect satisfies its specification

For any base system that satisfies the requirement P, the resulting augmented system from weaving the aspect according to its pointcut will satisfy result Q

Really?

Really. X

MAVEN Components: a prototype implementation

LTL model checker: NuSMV version 2Tableau generator: ltl2smvTableau+aspect weaver: custom scriptAspects: SMV-based description

Weaver

Tableau+aspect weaverOperates on the text of state machine descriptions in the SMV languageCurrent state pointcuts only

Aspects

Described in a self-contained file

PointcutAdvice machineBase machine requirementWoven machine result

Aspect 1 (again)

P = A G ((¬displ Λ reqd) → F displ)Q = A G ((displ Λ reqd) → X F displ)ρ = displ Λ reqd

A = disp reqd ¬displ reqd

Another example

A discount policy for prices in a retail store management systemExample of weakly invasive aspect Can (and do) have many policies, dynamically changing.Verified a “half-price off” policy for simple properties (“no item becomes free” ,..)

Aspect Verification: Summary

Prove once-and-for-all that an aspect satisfies its specificationModularGenericUses an LTL tableau as a “generic” model—much smaller than real basic modelsPrototype implementation

Still need to…

Develop examples to investigate:Useful forms of P and Q Expression of high-level constructs

Generalize to full weaving (many variants)Extend to fully invasive aspectsIdentify weakly invasive efficientlyImplement efficientlyConsider conflicts among multiple aspects