1 / 45

Aspect Verification: Summary

Detecting Interference or Proving Interference Freedom Among Aspects Shmuel Katz Computer Science Department The Technion. Aspect Verification: Summary. Prove once-and-for-all that an aspect satisfies its specification Modular Generic

senwe
Download Presentation

Aspect Verification: Summary

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Detecting Interference or Proving Interference Freedom Among AspectsShmuel KatzComputer Science DepartmentThe Technion

  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. 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. 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 fragilepointcut 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) publicinterface Persistent { ... } • 2) • 3) publicclass 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: Encrypt Log Decrypt Superimposition Protocol class Log Protocol class Encrypt Log Decrypt void sendData(String) void receiveData(String) Encrypt Log Decrypt Log Composition void sendData(String) void receiveData(String)

  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 Pair of LTL formulas 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 in anyreasonable base system for A unusual! For any base satisfying PA possibly global!

  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. 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 PAand PB

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

  24. Adding Password Encryption Aspect A, responsible for encryption. A’s pointcut: a password is sent from a login screen A’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. Aspect A: encrypt(password) System S: send (login, password) Internet terminal Server grant_access (info)

  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) Aspect B: e-mail retrieved psw. S+A: send (login, encr(password)) forgot psw. Internet terminal Server grant_access (info)

  28. Example – contd.(3) Unencrypted!!! (S+A)+B: B send (login, encr(password)) “forgot_psw.” pressed e-mail psw. Internet terminal Server grant_access (info)

  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) violatesthe guarantee of A (all passwords encrypted) B cannot be woven after A. 2. The presence of B (e-mailed passwords) violates theassumption 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 interferewith B if for every system S, (*) (*) Notation: OKAB both assumptions hold both 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 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 Composition A –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. Tψ Tψ Strategy – MAVEN tool by running NuSMV model-checker • 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 Representation of all the possible systems satisfying PA TP

  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 A Keeps the Assumption of B 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 B Keeps the Guarantee of A

  38. Incremental has advantages beyond generalization to N Cause: smaller models and TL formulas • Easier weaving • Quicker verification • Simplifications to 2 verification tasks (in not-so-rare special cases) • 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)

  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 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. Interference Detection in Java Systems(2) Atomicity, Consistency, Isolation, Durability • Planned: case study based on library ofreusableaspects 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

  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/

More Related