Runtime Verification of Contracts for Java Programs

1
Runtime Verification of Contracts for Java
Programs

• Christian Colombo
• Gordon J. Pace
• Gerardo Schneider
• FLACOS - November 2008

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() PROPE
RTY clcontract STATES BAD V
NORMAL S1 S2 STARTING Init
TRANSITIONS Init -gt S1 login Init
-gt V request Init -gt S2 logout S1 -gt
S1 login S1 -gt S1 request S1 -gt S2
logout S2 -gt S2 logout S2 -gt V
request S2 -gt 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

• ?

17
(No Transcript)
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

• 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 -gt loggedin goodlogin
• loggedout2 -gt loggedin goodlogin
• loggedout3 -gt loggedin goodlogin
• loggedout1 -gt loggedout2 badlogin
• loggedout2 -gt loggedout3 badlogin

PROPERTY two STATES NORMAL promptPW
goodlogin STARTING loadsite
TRANSITIONS loadsite -gt promptPW
PressOK\checkUserName() promptPW -gt
goodlogin PressOK\checkPassword()\gl.send(u)
promptPW -gt loadsite PressOK
METHODS boolean checkUserName()return
true boolean checkPassword()return true
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.

31
(No Transcript)
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 ss1
• ...

45
Events

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