1

Detecting Interference or Proving Interference Freedom Among Aspects

Shmuel KatzComputer Science DepartmentThe Technion

2

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

3

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

4

What does “Interference” mean?

Different meanings for different people Can look at “interference” between an

aspect and the base program Aspect disturbs desirable properties of the

base: should show that aspect “does no harm” as part of correctness of the aspect

Fragile pointcut problem: “innocent” changes in the base system change aspect joinpoints unintentionally

5

Treating the fragile pointcut problem

Fragile pointcuts: susceptible to ‘break’ when changes are made to the

(base) program. e.g. “call(void *.set*(Object))” Pointcuts are syntactic, but represent intentions

are implicitly present (encoded, hard-wired) in the sources of the program

Semantic property is an abstract notion; e.g. behavior of a program element, its intended meaning.

Should not rely on the 'accidental' structure and naming conventions of the program

Try to treat in language extensions (e.g., annotations, or extended interface)

6

Interference among multiple aspects

Usual view of interference Considered a problem in industrial

applications AOSD-Europe defined a task force to

analyze what it means, how common it is, and what to do about it

From now on: this is the kind we consider

7

Possible Views of Interference

Conflicts from introduction of added fields or methods (violate language rules)

Common joinpoints (both aspects need to be applied at the same place)

One adds or removes joinpoints of the other (relative to those in the base alone)

Note: all of above do not require knowing the intent of the aspect

8

Introduction conflicts

Account.counter is added by two different aspects, with different intentions

Account.update() method is added by two aspects with different definitions

AspectJ can’t detect these in advance, and by the time the bytecode is generated it is too late (even though Java itself could detect this if it were in a Java program)

9

A harder example 1) public interface Persistent { ... } 2) 3) public class BusinessObject implements Persistent

{ ... } 4) 5) aspect PersistenceImplementation { 6) void Persistent.saveChanges() { db.update(...); } 7) } 8) 9) aspect ObjectCache { ... 10) void BusinessObject.saveChanges(){ cache.setVal(...); } 11) }

The two versions of saveChanges are actually added to the same class but this would not normally be detected…

10

More introduction conflicts

Changing the inheritance hierarchy can make illegal cycles

Again, interfaces and aliasing can make these hard to detect

The Aspect Introduction Analyzer checks these for AspectJ, using a graph transformation tool called GROOVE

11

Interference at shared join points

depending on the composition operators

Can have one affect the other, or both relate only to base

dependencies among aspects e.g. conditional execution

affected by different orderings

12

Aspect Interference: Unintentional Common Joinpoints

How can this happen? Separation of concerns:

Pointcuts are developed separately Thus, we may not be aware of shared join points

Aspects are usually written in Turing complete advices AspectJ, AspectC++, AspectWerkz, JBossAOP …

This makes it hard to reason about the sanity of the composition

E.g. “What is the intended behavior of not calling the proceed in one specific around advice?”

13

Example: Encryption:

Encrypt all outbound traffic on some protocol call(* *.sendData(String)) && args(data) Encrypt advice

Decrypt all inbound traffic on some protocol call(* *.receiveData(String)) && args(data) Decrypt advice

Logging: Log all sent and received data on the protocol:

call(* *.receiveData(String) || * *.sendData(String)) && args(data) Log advice

14

Example:

Protocol class

voidsendData(String)

voidreceiveData(String)

Encrypt Log Decrypt

Protocol class

voidsendData(String)

voidreceiveData(String)

Encrypt Log

Log Encrypt

Decrypt Log

Log Decrypt

Superimposition

Composition

15

Example:

Both orderings are correct from a compiler point of view!

However, depending on the requirements one order might be intended. In a hostile domain we want to ensure that no

unencrypted data is read. In a protocol debugging domain we need to read

the unencrypted data.

Assume we want the latter option: Log before Encrypt and Decrypt before Log

16

Other examples “If the authorization aspect denies access for a state-changing operation, a second aspect may not be executed"

e.g. the authorization around advice does not do a proceed()

"combining a real-time constraint aspect and a (possibly blocking) synchronization constraint"

"two advices that both modify e.g. the arguments or return value of a call"

unless these are associative modifications

17

Aspect ordering Ordering of advice at shared join points

execution 'must' be sequential an order is always chosen

ordering may affect behavior desired order is determined by requirements!

explicit, finegrained ordering specification is required AspectJ: 'declare precedence' EAOP: advice composition () Compose*: declarative, fine-grained composition

specification ordering conditional execution static constraints

18

Specification-based Interference

Requirements/specifications of the two aspects are contradictory

One aspect “causes” another to not give the desired result (violate its guarantee) Called Semantic Interference Can happen even if the requirements

are compatible

19

Aspect Specifications

Specification of aspect A is (PA, RA)

The principle: assume – guarantee (generalized)A assumes: PA holds in the base system

what’s true at joinpoints global properties of base system properties of aspect parameters

A guarantees: RA in the woven base plus A new properties added by A properties of base system maintained in woven

system

possibly global!

in any reasonable base system for A

Pair of LTL formulas

unusual!

For any base satisfying PA

20

Interference Among Aspects

A, B – aspects; S – underlying system

(S + A) +B WRONGS + A OK OR

(S + B) +A WRONGS + B OK OR

S + (A+B) WRONG

21

Detecting Contradictory Specifications= Feasibility

Simply check whether the specifications are satisfiable together: give RA ⋀ RB to a SAT checker

Will see later that in our interference check of a library of aspects, more formulas need to be satisfiable.

22

Semantic Interference Among Aspects

When A and B are both woven to a base system S, at least one does not achieve desired result even though:

Aspect A satisfies its specification (PA, RA) Aspect B satisfies its specification (PB, RB) Base system S satisfies both PA and PB

23

Interference Example: Internet Access to Bank Accounts

Underlying system:

Internet terminal

Server

send (login, password)

grant_access (info)

24

Adding Password Encryption

Aspect A, responsible for encryption.A’s pointcut: a password is sent

from a login screenA’s assumption, PA: password-

containing messages are sent only from login screens

A’s guarantee, RA: each time a password is sent, it is encrypted

25

Example – contd.

Internet terminal

Server

send (login, password)

grant_access (info)

Aspect A: encrypt(password)

System S:

26

A later addition: Retrieve Forgotten Password

Aspect B adds a “forgot_password” button to the base system. When pressed, security questions are asked, and if they are answered correctly, B e-mails the forgotten password to the user.

B’s pointcut: “forgot_password” button is pressed

B’s assumption, PB: true (no assumption needed)

B’s guarantee, RB: each time a password is forgotten, it’s e-mailed to the user, provided the security questions are answered

27

Example – contd.(2)

Internet terminal

Server

send (login, encr(password))

grant_access (info)

Aspect B: e-mail retrieved psw.

S+A:

forgot psw.

28

Example – contd.(3)

Internet terminal

Server

send (login, encr(password))

grant_access (info)

Unencrypted!!!

(S+A)+B:

“forgot_psw.” pressed

B

e-mail psw.

29

Cause of the problem

Common join-points? – No. Updating shared variables? – No. Changing joinpoints? – Not as written. The semantics/specification of A and B? – Yes!1. B (resulting in e-mailed passwords) violates

the guarantee of A (all passwords encrypted) B cannot be woven after A.

2. The presence of B (e-mailed passwords) violates the assumption of A (passwords sent from Login Screen only) A cannot be woven after B

30

Semantic Interference – more formally

A – aspect, specified by (PA, RA)

B – aspect, specified by (PB, RB)

Definition: A does not interfere with B if for every system S,

(*)

(*) Notation: OKAB

( | ) (( ) | )A B A BS P P S A B R R both assumptions

holdboth guarantees

hold

31

Proving Non-Interference

Need to prove: OKAB and OKBA

Proof methods: Direct vs. Incremental Theorem (dividing the proof task):To prove OKAB, it’s enough to show

[KPAB]

[KRAB]

Proof using this theorem is incremental

(( | ) ( | ))A B BS S P P S A P

(( | ) ( | ))A B AS S R P S B R

A Keeps the Precondition of B

B Keeps the Result assertion of

A

32

The Incremental Method Generalizes to N

If N aspects pairwise satisfy KP and KR in both directions, for any combination of m N aspects from that set, there is no semantic interference.

Each one preserves the assumption and guarantee of all the others, so no matter how many are applied, all guarantees will hold if all assumptions held in the base

Direct method does NOT generalize to N

33

Feasibility of CompositionA – aspect, specified by (PA, RA)

B – aspect, specified by (PB, RB)

Definition: composition of A before B is feasible iff all the following formulas are satisfiable:

PA ⋀ PB (the assumptions are compatible)

RA ⋀ PB (the guarantee of A and the assumption of B are compatible)

RA ⋀ RB (the guarantees are compatible)

Can be a separate check to see if specs interfere

34

Automatic and Modular Interference Detection

Both for Direct and Incremental method The MAVEN tool – extended: improved and

adopted for interference-detection purpose Original purpose of MAVEN: automatic

modular verification of assume-guarantee aspect specifications

35

Strategy – MAVEN tool

Build a “generic” state machine version (TP ) of assumption PA a tableau

Weave the aspect (A) into this model Prove that this augmented generic model

(TP+A) satisfies the desired result, RA

TψTP Tψ

Representation of all the possible systems

satisfying PA

by running NuSMV model-

checker

36

Direct Proof Method

1. Build tableau T for PA PB

2. Use MAVEN to prove OKAB

- weave A into T, then weave B- show RA RB on the result

3. Use MAVEN to prove OKBA

- weave B into T, then weave A- show RA RB on the result (symmetric)

37

Incremental Proof Method

1. Use MAVEN to prove KPAB

- build tableau TP for PA PB

- weave A into TP

- show PB on the result

2. Use MAVEN to prove KRBA

- build tableau TR for RA PB

- weave B into TR

- show RA on the result

3, 4 (for KPBA, KRBA): symmetric ( OKBA)

OKAB

A Keeps the Assumption of B

B Keeps the Guarantee of A

38

Incremental has advantages beyond generalization to N

1. Easier weaving 2. Quicker verification3. Simplifications to 2 verification tasks

(in not-so-rare special cases)4. Advantage in failure analysis: Depending on the verification step with

a counterexample, we can often see which aspect caused interference and how (= which property was violated)

Cause: smaller models and TL formulas

39

Bank system example - reminder

S: system providing internet access to bank accounts. Involves sending passwords from “login” screen

A: aspect in charge of encoding the passwords sent from login screens

B: aspect in charge of retrieving forgotten passwords; sends them by e-mail

40

Bank system – verification failures

KRAB fails B can not be woven after A, because it does not preserve the guarantee of A, RA (the e-mailed password will be unencoded)

KPBA fails B can not be woven before A, because B violates the assumption of A, PA (the passwords are sent not only from the “login” screen)

41

Running the example

Incremental method has model sizes from ¼ to ½ the size of the direct method.

Identifying errors is much easier Validates advantage of incremental Also has complexity analysis that

model sizes are smaller than direct interference proof by exponential factor

42

More Interference Detection in Java Systems

Work in progress : industrial case studyToll System (Siemens) – controlling toll roads Formalization of aspect specifications Translating advice to transition systems Verification of aspects and interference

detectionIntermediate results: Interference between two aspects found and is

being analyzed now (between aspect for fines and aspect for discounts)

43

Interference Detection in Java Systems(2)

Planned: case study based on library of reusable aspects that implement ACID properties for transactional objects

Large library of aspects, intended to be used as benchmark

Authors state there is interference between the aspects

Goal: formalization, analysis => interference warnings and non-interference proofs for the aspects => usage guidance for the library

Atomicity, Consistency, Isolation, Durability

44

Current State of Interference Proofs

The proof method has been successfully applied to several examples and variants

MAVEN tool has been improved Work in progress: - refining the proof method and error analysis

connect to more forms of weaving

- interference guidelines for real aspect libraries

More detailed information in E. Katz, S. Katz, “Incremental Analysis of Interference Among Aspects”

FOAL Workshop, 2008.

45

Common Aspect Proof Environment (CAPE)

Collection of verification and analysis tools for aspects, in an integrated Eclipse environment

Includes MAVEN, AIA, and 9 other tools Check it out at:

http://www.cs.technion.ac.il/~ssdl/research/cape/