A Framework for Runtime Enforcement Systems

1. A Framework for Runtime Enforcement Systems Somayeh Malakuti, Mehmet Aksit, Christoph Bockisch Software Engineering Group http://trese.cs.utwente.nl

2. Outline • Runtime Enforcement • Definition • Concerns • Implementation • Requirements • The E-Chaser RE Framework • Conclusion & Future Work

3. input output Application internal states correction RE System Definition of Runtime Enforcement • Nowadays, application software is becoming more and more complex, therefore: • it is not possible to detect all the failures of the software before its actual deployment. • the existing verification and validation techniques may not scale up. • Runtime Enforcement (RE): • verifies the active execution trace of software against formally specified properties. • if properties are violated, diagnosis the cause of failure, and enforces the properties.

4. Concerns in Runtime Enforcement Monitoring Components Application Programs Events /States Observer Properties Recovery Observer Verification Events /States Observer Healing Events/ States Observer Diagnosis Events /States Diagnosis Components Recovery Components Predicates Strategies

5. Events /States Properties Recovery & Diagnosis Actions Current Trend in Runtime Enforcement Specifications are more declarative and abstract then the actual programs Specification Verification Compiler Source Files Modified Source Files Observers Monitoring Components Diagnosis Components Recovery Components

6. Variation of the Concerns May be modularized in different ways: layers, components, etc. Multiple Inter-Related Properties Inlined or outlined Properties may be expressed in various formalism Monitoring Components Application Programs Events /States Observer May be distributed or centralized Properties Recovery Observer Verification Events /States May be implemented in multiple languages Observer Healing Events/ States Observer Diagnosis Events /States Diagnosis Components Recovery Components Predicates Strategies Various strategies, which may interfere with each other Various predicates, based on types of failures, properties,…

7. An Example Runtime Enforcement Approach SafeFileWriter(FileWriter f) { event open after() returning(FileWriter f) :call(FileWriter.new(..)) {} event write before(FileWriter f) :call(* write(..)) && target(f) {} event close after(FileWriter f) : call(* close(..)) && target(f) {} ere : (open write write* close)* @fail { System.out.println(“error!"); __RESET; } @match { System.out.println(“matched!”) ; } } Events declarative Property Imperative Recovery Code An example specification in Java-MoP

8. Requirements for a Runtime Enforcement Framework • To reduce the complexity, to foster reuse and flexibility, the RE systems must separate and compose the concerns in an effective manner: • represent each concern modularly using appropriate language constructs, and provide mechanism to integrate the concerns. • provide appropriate mechanisms for the composition of concerns, so that more complex concerns can be defined based on the existing concerns. • be independent of the application language. • be transparent of the distribution of application programs.

9. The E-Chaser RE Framework • We developed E-Chaser runtime enforcement framework to address the mentioned requirements. • E-Chaser provides modular and orthogonal extensions to basic programming languages using the notion of filters. • Filters are bound to the program objects, and react to events.

10. The E-Chaser RE Framework • Each filter has a type that implements a singleconcern: • a concern can be a simple actions such as dispatching messages, logging messages, buffering messages, etc. • a concern can be more complex, such maintaining the history of execution, verifying the history against a predicates, taking a recovery action, etc. close open write read filter: Log Interface Part Methods File Object

11. eNotAuth : BooleanDetector Specification of Filters: separation & composition of concerns close open write read eAllFileErrors : BooleanDetector logger :Log preventer :Prevent ePattern (violated) eAllFileErrors (satisfied) ePattern : RegularExpression eNotAuth (satisfied) methods File Object • We distinguish between two categories of filter types: • Events do not have functional side-effect, • Responses are filters with can have functional side-effect.

12. The E-Chaser RE Framework • The E-Chaser language provides constructs • to define events and responses. • to compose events with each other to form composite events • to compose responses with each other to form composite responses • to integrate events with responses • the language is independent of both the distribution and the language of the software • The E-Chaser compiler • reasons about the distribution of software • generates codes for the filters based in the same language as the software

13. Monitoring Components Application Components Messages /States Observer Properties Recovery Observer Verification Messages /States Observer Response:Type Response:Type Recovery Components Healing Messages/ States Observer Diagnosis Messages /States Diagnosis Components Strategies Rules Composite Event :Type Event:Type Event:Type Application Object Application Object Did We Achieve the Separation and Composition of Concerns?

14. Published & ISSRE 2009 To be submitted to DSN 2011 Submitted to AOSD 2011

15. Future Work • Finalizing the implementation of the framework. • Distribution-transparency for multiple-language software. • An ongoing master project. • Synthesizing optimum inline or outline monitors based on the specification (?)

16. Question?