1. 1 Detecting Interference or Proving Interference Freedom Among Aspects Shmuel Katz Computer Science Department The Technion

2. 2 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

3. 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 aspects Identify weakly invasive efficiently Implement efficiently Consider conflicts among multiple aspects

4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 14 Example: Protocol class void sendData(String) void receiveData(String) EncryptLogDecrypt Protocol class void sendData(String) void receiveData(String) EncryptLog Encrypt DecryptLog Decrypt Superimposition Composition

15. 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. 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. 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. 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. 19 Aspect Specifications Specification of aspect A is (P A, R A ) The principle: assume – guarantee (generalized) A assumes: P A holds in the base system what ’ s true at joinpoints global properties of base system properties of aspect parameters A guarantees: R A 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 P A

20. 20 Interference Among Aspects A, B – aspects; S – underlying system (S + A) +B  WRONG S + A  OK OR (S + B) +A  WRONG S + B  OK OR S + (A+B)  WRONG

21. 21 Detecting Contradictory Specifications= Feasibility Simply check whether the specifications are satisfiable together: give R A ⋀ R B to a SAT checker Will see later that in our interference check of a library of aspects, more formulas need to be satisfiable.

22. 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 (P A, R A ) Aspect B satisfies its specification (P B, R B ) Base system S satisfies both P A and P B

23. 23 Interference Example: Internet Access to Bank Accounts Underlying system: Internet terminal Server send (login, password) grant_access (info)

24. 24 Adding Password Encryption Aspect A, responsible for encryption. A ’ s pointcut: a password is sent from a login screen A ’ s assumption, P A : password- containing messages are sent only from login screens A ’ s guarantee, R A : each time a password is sent, it is encrypted

25. 25 Example – contd. Internet terminal Server send (login, password) grant_access (info) Aspect A: encrypt(password) System S:

26. 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, P B : true (no assumption needed) B ’ s guarantee, R B : each time a password is forgotten, it ’ s e-mailed to the user, provided the security questions are answered

27. 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. 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. 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. 30 Semantic Interference – more formally A – aspect, specified by (P A, R A ) B – aspect, specified by (P B, R B ) Definition: A does not interfere with B if for every system S, (*) (*) Notation: OK AB both assumptions hold both guarantees hold

31. 31 Proving Non-Interference Need to prove: OK AB and OK BA Proof methods: Direct vs. Incremental Theorem (dividing the proof task): To prove OK AB, it ’ s enough to show [KP AB ] [KR AB ] Proof using this theorem is incremental A Keeps the Precondition of B B Keeps the Result assertion of A

32. 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. 33 Feasibility of Composition A – aspect, specified by (P A, R A ) B – aspect, specified by (P B, R B ) Definition: composition of A before B is feasible iff all the following formulas are satisfiable: P A ⋀ P B (the assumptions are compatible) R A ⋀ P B (the guarantee of A and the assumption of B are compatible) R A ⋀ R B (the guarantees are compatible) Can be a separate check to see if specs interfere

34. 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. 35 Strategy – MAVEN tool Build a “ generic ” state machine version (T P ) of assumption P A a tableau Weave the aspect (A) into this model Prove that this augmented generic model (T P +A) satisfies the desired result, R A TψTψ TPTP TψTψ Representation of all the possible systems satisfying P A by running NuSMV model-checker

36. 36 Direct Proof Method 1. Build tableau T for P A  P B 2. Use MAVEN to prove OK AB - weave A into T, then weave B - show R A  R B on the result 3. Use MAVEN to prove OK BA - weave B into T, then weave A - show R A  R B on the result (symmetric)

37. 37 Incremental Proof Method 1. Use MAVEN to prove KP AB - build tableau T P for P A  P B - weave A into T P - show P B on the result 2. Use MAVEN to prove KR BA - build tableau T R for R A  P B - weave B into T R - show R A on the result 3, 4 (for KP BA, KR BA ): symmetric (  OK BA )  OK AB A Keeps the Assumption of B B Keeps the Guarantee of A

38. 38 Incremental has advantages beyond generalization to N 1. Easier weaving 2. Quicker verification 3. 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. 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. 40 Bank system – verification failures KR AB fails  B can not be woven after A, because it does not preserve the guarantee of A, R A (the e-mailed password will be unencoded) KP BA fails  B can not be woven before A, because B violates the assumption of A, P A (the passwords are sent not only from the “ login ” screen)

41. 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. 42 More Interference Detection in Java Systems Work in progress : industrial case study Toll System (Siemens) – controlling toll roads Formalization of aspect specifications Translating advice to transition systems Verification of aspects and interference detection Intermediate results: Interference between two aspects found and is being analyzed now (between aspect for fines and aspect for discounts)

43. 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. 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. 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/