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 propositions Temporal operators: Gp Fp Xp pUq Path quantifiers: A for all path E there exists a path

Aspect Specification Aspects also have an assume-guarantee specification Requirements about base system Results 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 A Pointcut: descriptor ρ Specification: Base machine requirement P Woven machine result Q P and Q are LTL

Interpreting the specification Correctness assertion of an aspect: For all base machines B If “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 system Not modular Can do generic set-up using aspects to annotate augmented system Sihman and Katz Extending CTL properties Given a particular base system Krishnamurthi, 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 - Set of states. I  S - Initial states. R  S x S - Total transition relation. L: S  2 AP - 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,ba a b,c c a,c a,b b

Another State Machine

Fairness Problem with nondeterminism: often allows the system to “do nothing” forever Impose a fairness constraint, and only look at fair paths Fairness 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  =s 0 s 1 s 2... is a path in M from s iff s = s 0 and for every i  0: (s i,s i+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: p  AP Boolean operators: f  g, f  g AX f, A(f U g), AG f, AF f EX 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 P Weave the aspect into this model Prove that this augmented generic model satisfies the desired result TψTψ TPTP TψTψ

State Machines (Reminder) Finite set of states S Set of atomic propositions AP Labeling function L : S → 2 AP Path relation R containing pairs (s,t) when there is a transition from s to t Fairness set (states that must be visited infinitely often)

LTL Formulas (Reminder) A F c A F G ¬b A G ((¬a Λ b) → F a)

Base Machine State machine B Computation starts from one of the initial states S 0  S

Base Machine S0S0

Advice State machine A Initial states S 0 Return states S ret S 0 S ret

Pointcuts Pointcut descriptor ρ Matches the end of a path Past LTL, regular expressions,...

Pointcut ρ = a Λ Y b Λ Y Y b ? ? ?

Components for modular model checking of aspects State machines Fairness LTL Base machines Aspect advice machines Aspect pointcuts

Weaving Inputs: Base machine B Aspect machine A Pointcut ρ 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 pointcut Matching states are labeled ‘pointcut’ Done on the base machine, before weaving Has the same collection of paths (so LTL assertions are unchanged)

1. Pointcut-Ready Advantage: simplicity Disadvantage: doesn’t handle all situations (especially pointcuts inside aspect states, or when aspects invalidate pointcuts in base) No problems for many aspects State pointcut Method call pointcut

1. Pointcut-Ready ρ = a Λ Y b Λ Y Y b

2. Augmenting Transitions from base machine ‘pointcut’ states to aspect initial states Transitions from aspect return states to base machine states According to state labels

2. Augmented Rule: add all edges ‘pointcut’ → aspect initial aspect return → base Where the labels exactly match Remove 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 Spectative Regulative Invasive 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 Prove For all base machines B If “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 T P Exactly all the paths which satisfy a given LTL path formula TPTP

Tableau G a

Tableau F b

Tableaux For a given LTL formula P If a path supports the formula, it must be in the tableau For any machine satisfying P All its paths must be in the tableau

Recall Advice: state machine A Pointcut: descriptor ρ Specification: Base machine requirement P Woven 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 T P, the tableau for P T P TPTP

Step 2 Restrict T P to its reachable component

Step 3 Weave A into T P according to ρ Result: T ͠ P T ͠ P If can’t reconnect—aspect is not weakly invasive TψTψ

Step 4 Determine if T ͠ P |= Q orange TψTψ

Claim If T ͠ P |= Q Then for any B If B |= P And A and ρ are weakly invasive for B Then B ̃ |= Q

Proof Outline T P has every possible path satisfying P So T P ͠ has every possible augmented path B satisfies P, so every path of B corresponds to a path through T P If T ͠ P |= Q Then 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 =

T P for AG((¬a Λ b) → Fa) (g = Fa) TPTP

T͠PT͠P TψTψ

T ͠ P |=AG((aΛb) → XFa) Tψ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 2 Tableau generator: ltl2smv Tableau+aspect weaver: custom script Aspects: SMV-based description

Weaver Tableau+aspect weaver Operates on the text of state machine descriptions in the SMV language Current state pointcuts only

Aspects Described in a self-contained file Pointcut Advice machine Base machine requirement Woven 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 system Example 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 specification Modular Generic Uses an LTL tableau as a “generic” model—much smaller than real basic models Prototype 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 aspects Identify weakly invasive efficiently Implement efficiently Consider conflicts among multiple aspects