Composition, reuse, and interaction of Stateful Aspects.

1. Composition, reuse, and interaction of Stateful Aspects. By Nathanel Mori Based on the work of Douence, Fradet, and Sudholt.

2. What are we looking for? • Aspect technology is far from maturity. There is much more work to be done in the theoretical field. • One of the main questions that has to be asked is concerned with different kinds of conflicts. • Aspects are not always orthogonal and aspect interaction is a fundamental problem.

3. What is proposed • Stateful Aspects – A completely independent, generic framework for the formal definition and interaction analysis of aspects. • 3 extensions which enable the interaction of aspects in various ways. • The result – A more precise analysis of aspects and an important step towards an efficient technique of composing, reusing and interacting aspects.

4. The main idea • We need aspects to know as much info about the base program as possible. • The definition of cross-cuts or join-points as single points in the code is incorrect. A history of the execution process has to be kept. Hence  Trace-Based Aspects.

5. Trace-Based Aspects • “Trace-Based Aspects” is a model of aspects which takes into account the history of program execution. • Weaving is achieved using a monitor that modifies program execution. • Trace-Based Aspects create an important tradeoff between expressiveness and property enforcement/analysis.

6. Necessity of Trace-Based Aspects: Example • An access control code for logged-in users. • The aspect would have to know who is logged-in right now. • The programmer would add an extra insert (or advice) to set a flag in the base program login code. • The aspect must be modified to recognize this flag. • Low reusability level for such an aspect.

7. Characteristic of Trace-Based Aspects • There are 3 main characteristics to Trace-Based Aspects: • Observable Execution Trace • Aspect Language • Weaving

8. Observable Execution Trace • A monitor observes the execution and gives semantic meaning to the join-points. • Example: • A join-point can be a term like login(“Bob”). • If the code is login(user) for user=“Bob”, then the monitor should recognize it.

9. Aspect Language • 3 important terms are defined: • Crosscuts • Inserts • Stateful Aspects

10. Aspect Language: Crosscuts • A crosscut is a function. • When C is given a crosscut definition, it returns “fail” if it didn’t satisfy it or a substitution in case it did. • Example: If C should detect Bob logging in, • C(logout()) = fail, C(login(“Alice”)) = fail. • but C(login(“Bob”))=“Bob”. The substitution is referred to as uid in the future.

11. Aspect Language: Inserts • An Insert is an executable program (or program fragment) with free variables. • The free variables are bound by the output of the crosscut function. • Example: The insert addLog(uid+”logged in”) prints the name of the logged-in user.

12. Aspect Language: Stateful Aspects • Intuition:C uI is an aspect. It states that when C matches the current join point and yields a substitution , then I is executed (I bound by ). • Examples: • isLogin u addLog(uid+”logged in”) • While (true) {isLogin u addLog(uid+”logged in”)} • This enables us to log all sessions.

13. Weaving • Aspects, as we have seen in the past, can be composed and woven together. • The weaver takes a parallel composition A1||A2||……||An, and tries to apply each of them at each join point of the execution trace, in no specific order. • The weaver can be regarded conceptually as an execution monitor who dynamically selects which code to run.

14. Weaving • When a basic aspect Ai has been applied and its insert has been executed, Ai evolves into its next state – hence the title “Stateful Aspects”. • Example: • while(true) {isLogin uaddLog(uid+”logged in”) ; isLogout u addLog(uid+”logged out”)} - The semicolon (“;”) denotes a switch of states.

15. Instantiation • Up until now, we’ve suggested a general framework to describe Trace-Based Aspects. The framework included a monitor, a language, and a weaving concept. • Now all we have to do is define an instantiation to the framework.

16. Instantiation • We will learn about 3 different instantiations of the framework, as follows: • Expressive Aspects and Equational Reasoning. • Detection and Resolution of Aspect Interactions. • Static Weaving of Safety Properties. • Each instantiation will include: • Definition of crosscuts, inserts, and stateful aspects. • Demonstration of expressiveness vs. property enforcement/analysis.

17. Expressive Aspects and Equational Reasoning • Definitions: • Crosscuts – A crosscut C may be an arbitrary predicate. • Example:isWeakPassword may recognize a string that is exposed to dictionary attack. We are not concerned with implementations. • Inserts – Defined as simple program fragments, like in the framework.

18. Expressive Aspects and Equational Reasoning • Definitions cont. • Stateful Aspects – A collection of mutually recursive definitions of the form var = A. • Such aspects are based on the following grammar: ; basic aspect ; sequence ; choice ; invocation

19. Expressive Aspects and Equational Reasoning • This grammar allows us to compose aspects by sequentialization, deterministic choice, and aspect invocation. • The choice option, , is deterministic. Therefore, it selects A1 automatically unless it is not applicable. In that case, A2 is selected iff it is applicable. • Example:

20. Expressive Aspects and Equational Reasoning • Note the great expressivity that the language has. The following example elaborates this further. • Example:

21. Expressive Aspects and Equational Reasoning • The example demonstrated shows how to detect nested logins (non top-level): • logNestedLogin catches the first login and then relies on log to detect and log pairs of logins and logouts. • What happens if an aspect from a different origin interferes with the operation of these aspects?

22. Expressive Aspects and Equational Reasoning • Problem: Consider the following aspect: • It’s very easy to prove that this aspect along with logNestedLogin are equivalent to a single sequential aspect. • The result is obvious:

23. Expressive Aspects and Equational Reasoning Here’s your chance to view it all together: Composed with: Gives us:

25. Detection and Resolution of Aspect Interactions • By restricting the expressiveness of the language, we can automatically prove aspect properties. • This is the second instantiation proposed for the aspect framework which had been introduced.

26. Detection and Resolution of Aspect Interactions • Definitions: • Crosscuts – A crosscut C may be only a conjunction, disjunction, or a negation of a term. C is denoted formally in this formula: where T denotes terms with variables. Example:

27. Detection and Resolution of Aspect Interactions The above regular expression denotes that root can log into any machine, or that any user can log into any machine excluding the server. • Note that we have lost some expressiveness by regarding join points as term patterns which make the decidability feasible (as opposed to arbitrary predicates from the previous method).

28. Detection and Resolution of Aspect Interactions • Definitions: • Inserts – As before, simply a program fragment. • Stateful Aspects – The main idea in this definition of stateful aspects is to restrict them to regular expressions using this grammar:

29. Detection and Resolution of Aspect Interactions • Example: The following example demonstrates a security aspect logAccess that logs file accesses (calls to read) from a call to login until a call to logout. (non-nested sessions) • X matches the name of the accessed file.

30. Detection and Resolution of Aspect Interactions • Aspect Interactions: As you recall, the parallel weaving of aspects doesn’t tell us anything about the order in which they’ll be executed (A1 || A2 || … || An). • Also, we may not always be as lucky as we were in the previous example with the aspect initAtFirstLogin.

31. Detection and Resolution of Aspect Interactions • Aspect Interactions cont. • Example: Consider the following example – • How does it conflict with this?

32. Detection and Resolution of Aspect Interactions • Aspect Interactions cont. • The algorithm to check aspect interactions: • Similar to that of finite state product automata. • The algorithm eliminates the operator “ || “ by producing all the possible pairs (conjunctions) of crosscuts. • A crosscut with no solution cannot match any join point and therefore is removed from the aspect.

33. Detection and Resolution of Aspect Interactions • Aspect Interactions cont. • In our case, the algorithm produces: • The symbol urepresents conflicts. I1uI2 returns either I1;I2 or I2;I1. Here,

34. Detection and Resolution of Aspect Interactions • Aspect Interactions cont. • Note that spurious conflicts have been eliminated using the rule: • The analysis does not depend on the program to be woven. This static analysis is enough to prove there is an aspect interaction.

35. Detection and Resolution of Aspect Interactions • Support for Conflict Resolution: • Obviously, if no conflicts have been detected, then the aspect may be composed in parallel without modification. • In case conflicts are detected, then here are a few linguistic suggestions on how to handle this case: • Creating an Insert: For a conflict like Cu(I1uI2), the programmer may create an insert I3, who solves the non-determinism by choosing what to do – a solution which can get pretty tedious. Solution at aspect level 1: The operator ||seq indicates that whenever a conflict involving I1 and I2 occurs, it should be replaced by I1 ; I2. Solution at aspect level 2: The operator ||fst replaces (I1uI2) with I1 only.

36. Detection and Resolution of Aspect Interactions • Let’s examine the following examples: • logAccess ||seq cryptRead • This would generate plaintext logs for superusers. • cryptRead ||seqlogAccess • This would generate encrypted logs for user accesses.

37. Static Weaving of Safety Properties • The previous restrictions were unable to detect semantic interactions. • In other words, the code inserted by the aspect may still influence the application of another aspect, without our detecting it. • Therefore, we have to restrict the inserts language as well.

38. Static Weaving of Safety Properties • Definitions: • Crosscuts – As in the previous section. • Stateful Aspects – As in the previous section. • Inserts – Are generated by the following grammar:

39. Static Weaving of Safety Properties • In other words, these aspects can only make sure that no “bad things” happen during the execution. • Shortly, these are Safety Properties. • The benefits: • Aspects are semantic properties and therefore the impact of weaving processes are clear. • There are no interactions between aspects, which means they can now be composed freely in parallel. (the ultimate goal!)

40. Static Weaving of Safety Properties • The downside: • Executions have the aspects “watch from above” and throw an exception when the security policy is violated. However, that “watching from above” costs a terrible amount of run-time.

41. Static Weaving of Safety Properties • Example: • A critical action must have the clearance of the accountant and the manager.

42. a m c m a c c c Static Weaving of Safety Properties • Let’s examine the equivalent automaton: • a = accountant() • m = manager() • c = critical()

43. Static Weaving of Safety Properties • Weaving Phases: • Base Program Annotation. Since the aspect is regarded by the weaver as an automaton, then the weaver’s phase would be to create a “connection” between code lines from the base program and the transition of the automaton. There are various techniques to optimize this process. • Base Program Abstraction. The base program is abstracted into a graph G=(V,E). • V (the nodes) represents program points. • E (the edges) represents instructions (events). • This phase makes the next 2 phases independent of a specific programming language.

44. Static Weaving of Safety Properties • Weaving Phases cont. • Instrumentation. This phase transforms the graph in order to rule out forbidden sequences of events. Intuitively, this phase inserts the automaton transitions right before the very code it mimics, hence it creates the effect of checking whether the property is about to be violated. • Optimizations. The instrumented graph is refined in three steps: • Step 1 – Since the automaton defines a property independent of the program, then we need to specialize the automaton with respect to the base program. • Step 2 – Classical automaton minimization could really come in handy here. • Step 3 – Static analysis is performed to eliminate obvious and useless checks.

45. Static Weaving of Safety Properties • Weaving Phases cont. • Concretization. The optimized graph is now translated back into a program. Note that the new program is pretty close to the base program since the graph represented program points and instructions. We just need a global way to fetch, store, and test values – which could easily be done using global variables (to represent the automaton states).

46. Base Program Aspect Annotation & Abstraction Graph Instrumentation Instrumented Graph Optimization Instrumented Graph Concretization Program Static Weaving of Safety Properties