Runtime Verification of Contracts for Java Programs

1. Christian Colombo Gordon J. Pace Gerardo Schneider FLACOS - November 2008 Runtime Verification of Contracts for Java Programs

2. RV & Contracts In SOA we are concerned with security and trust. Model checking is not scalable. Testing lacks coverage. Particular behaviour only emerges during normal use of service composition. Runtime verification monitors the behaviour during runtime, scales up. Real-time properties / overheads. Contracts may have conflicts.

3. Runtime Verification Monitored System VERIFYING SYSTEM FEEDBACK EVENTS ----------------------------Specification ----------------------------

4. Runtime Verification Monitored System VERIFYING SYSTEM FEEDBACK EVENTS ----------------------------Contracts ----------------------------

5. Runtime Verification Monitored System Contract conflict analysis VERIFYING SYSTEM FEEDBACK EVENTS --------------Deontic Contracts --------------

6. Dynamic Automata with Timers & Events (DATE) • Communicating symbolic automata enriched with events and timers. • Automata are automatically replicated according to context: hence dynamic. • Supports: • Conditions and actions on transitions • Real-time • Communication between automata

7. An Example (1)

8. An Example (2)

9. LARVA - Architecture System Monitoring SYSTEM (Symbolic Automaton Execution) FEEDBACK AspectJ Matching method names EVENTS Report USER

10. Contract Language Example

11. Contract Language to Automata

12. Contract Language to LARVA EVENTS { login = {*.login()} logout= {*.logout()} request= {*.requestItem()} } PROPERTY clcontract { STATES { BAD { V } NORMAL { S1 S2 } STARTING { Init } } TRANSITIONS { Init -> S1 [login] Init -> V [request] Init -> S2 [logout] S1 -> S1 [login] S1 -> S1 [request] S1 -> S2 [logout] S2 -> S2 [logout] S2 -> V [request] S2 -> S1 [login] } }

13. Contradictions in Contracts request Contradiction Detected! O(request) request

14. Ongoing Work • Working closely with industry • Guarantees on the effect of monitoring – memory and time • Identifying better notations • Investigating compensable actions

15. Conclusions • Mathematical framework – DATE • Implemented useable tool – LARVA • Highly expressive (incl. real-time) • Evolving theory with practical guarantees • Can monitor contracts • Find contradictions in contracts • Future prospects of collaboration and improvement of current framework

16. Questions • ?

18. A Scenario – Dynamic Triggers • Imagine we need to check login/logout for each user. • We have to trigger an automaton for every user, to keep track whether each user is logged in or not. • Use method parameters to get context.

19. Specifying Properties • Intuitive, clear and succinct logic. • Understandable and useable by developers. • Includes all the required expressive power. • Automatically instrumentable in the target system. • Low overheads (eg. Determinism)

20. Simple Examples • Ensuring that only authorised users access reserved areas in the system. • Checking that a train gate which started closing has indeed closed after a number of seconds. • Monitoring the life-cycle of an object (such as a transaction), ensuring it goes through its stages properly.

21. Specifying Context • Actions and conditions on transitions can access the context (User). • A context can be nested to have a more specific context within it: • Eg: Check login for each site of each individual user.

22. LARVA - Architecture System LARVA ------------------- ------------------- EVENTS & PROPERTIES ------------------- USER

23. LARVA - Architecture (2) AspectJ Matching method names LARVA ------------------- ------------------- EVENTS & PROPERTIES ------------------- Monitoring SYSTEM (Symbolic Automaton) COMPILER

24. Recall Scenario Trigger new automaton FOREACH user PressOK \ checkUserName() Load Site Prompt for PW PressOK \ checkPassword() \ Goodlogin ! PressOK Good Login Trigger new automaton FOREACH user ChGoodlogin? Logged in Logged out ChGoodlogin? Logged out ChGoodlogin? Badlogin Logged out Badlogin Bad logins Badlogin

25. LARVA – Script PROPERTY two { STATES { NORMAL { promptPWgoodlogin } STARTING { loadsite } } TRANSITIONS { loadsite -> promptPW [PressOK\checkUserName()] promptPW -> goodlogin [PressOK\checkPassword()\gl.send(u);] promptPW -> loadsite [PressOK] } } } } METHODS { booleancheckUserName(){return true;} booleancheckPassword(){return true;} } GLOBAL { FOREACH (User u) { VARIABLES { Channel gl; } EVENTS { goodlogin() = {gl.receive(User u1)} where {u = u1;} pressOK() = {*.pressedOK(u1)} where {u = u1;} badlogin() = {*.loginTry(u1)} where {u = u1;} } PROPERTY one { STATES { BAD { badlogins } NORMAL { loggedout2 loggedout3 loggedin } STARTING { loggedout1 } } TRANSITIONS { loggedout1 -> loggedin [goodlogin] loggedout2 -> loggedin [goodlogin] loggedout3 -> loggedin [goodlogin] loggedout1 -> loggedout2 [badlogin] loggedout2 -> loggedout3 [badlogin] loggedout3 -> badlogins [badlogin] } }

26. LARVA - Compilation into Java • AOP to capture events. • A hierarchy of classes: one for each context. • Each class has a reference to its parent context. (E.g. The account context, have access to the user context.) • A hashmap to keep track of the distinct objects which we are checking.

27. Case-Study (2): Properties • Logging of credit card numbers – no risk of exposing sensitive information. • Execution of transactions – correct progress through states. • Authorisation transaction – transaction consistency. • Backlog – retries in case of failure.

28. Case-Study (3): - Experience • A lot of interesting properties are relatively simple. • Intuitive definition of properties. • Identified shortcomings of Larva and it was extended. • RV helps in clearly identifying requirements. • Integration in system life cycle.

29. Benchmark – Expressivity

30. Benchmark – Performance • Dummy transaction processing system (4 properties – 2 real-time) • Memory and time required is considerable but linear to the number of objects being monitored (replication of automata). • Compares well with Java-MOP which is the most similar work available for usage.

32. AOP • Automatic code weaving using pointcuts and advises. • Pointcut: call(* *.*(..)) • d.bark(b) && target(d) && args(b) • Advise: before, after, around • before (Dog d, Bark b): pointcut(d,b){ spotACat(); }

33. Other Events • Upon return: upon the return of a method (rather than the entry of the method). • Upon exception thrown: rather than simple method call, we can trigger the automaton upon an exception throw.

34. Other Events (2) • Upon exception handling: rather than simple method call, we can trigger the automaton upon the start of a catch block. • Clocks: trigger the automaton upon the elapse of an amount of time. • Channels: an automaton can trigger another automaton.

35. Object Equality • What if an object does not implement an equals method? • The user can specify which attributes of the object constitute the context. • E.g. A transaction is the same as long as it has the same id.

36. Invariants • What if some attributes of an object should not change? • The user can specify these attributes. • E.g. A transaction should remain with the same amount once the amount is set.

37. Chained Transitions • Should we allow transitions to trigger other transitions? • This could lead to an infinite loop! • So we disable aspects within the aspect code itself. • But we allow the user to take the risk with channels...

38. Determinism • For easier execution of the automaton, we opted for determinism. • The user specifies the order of transitions as they are written down in the script file.

39. Overhead of Verification (1) • Depends on a number of factors: • The actions the user puts on transitions. • The statements in the where clauses. • The amount of objects that the user keeps context of. • Very difficult to give an upper-bound because of the amount of freedom we give the user.

40. Overhead of Verification (2) • But we can guarantee the maximum memory overhead of our system… • …given that the user does not add other method calls on transitions. • We use Lustre so that the memory can be calculated at compile-time.

41. Real-Time Issues • Because of the Java Garbage Collection there is a limit to accuracy that we can give. • Using Java wait method is quite good within a certain number of milliseconds.

42. Real-Time Issues (2) • Consider a system which satisfies all its properties. • Will the properties still hold if we introduce the monitoring? • We provide a fragment of Duration Calculus which is “slow-down invariant”.

43. Compiler • The Compiler and Parser Manual are available at: • www.cs.um.edu.mt/~svrg/Tools/LARVA/ • christiancolombo.com/academic-masters-tools.html • Feel free to use it and give us feedback.

44. Nesting – Context within Context • FOREACH (User u){ • ... • FOREACH (Site s) • { • EVENTS{ • Login() = {User u1.login(Site s1)} • where {u = u1; s=s1;} • } • ... • }

45. Events • System Events – method call, method return, exception throw, exception handling. • Channel Communication. • Clock Timeouts.