Harmless Advice Daniel S Dantas Princeton University with Prof. David Walker

2 Aspect-Oriented Programming Large Program Want to add a new logging feature that references many parts of the program

3 Aspect-Oriented Programming  When? (Pointcut)  What? (Advice) Added Functionality (Logging) Join Points Aspect = Pointcuts + Advice + State

4  No “Tangling” To understand original functionality, examine mainline code  No “Scattering” To understand added logging functionality, examine logging advice only  Easy Consistency Checking To audit added logging code for consistency, simply analyze pointcut that triggers logging advice AOP Advantages Logging Advice

5 But Beware!  Advice may change state & break data invariants in the mainline code  To understand mainline code behavior, must examine main program + all aspects  Aspects prevent local reasoning Advice

6 Our Goals  Want the flexibility of aspect-oriented programming  Want to preserve traditional local reasoning principles Want to be able to understand the fundamental behavior of the mainline code without having to examine all the auxiliary aspects

7 What is harmless advice? Contributions  Defined a new “harmless” form of advice Harmless advice does not interfere with main program code Harmlessness is enforced by a type system for information flow control Proved a noninterference property for the language Conducted a case study demonstrating harmless advice is useful for enforcing security invariants What does that mean?  A spectrum of “interfering” effects: Doing work of any kind (alters timing) Looping or early exit (alters termination) Writing to a file (alters observations of the file system) Writing to a mutable mainline data structure  Criteria impacting our choice: Must help AOP programmers preserve local reasoning about main program code Must be enforceable Must admit common AOP applications

8 What Are Aspects Used For?  AspectJ Users List - What do you use aspects for? “…a reusable logging aspect” “...I use tracing, profiling, and policy enforcement aspects on virtually every project I work on” “…And the standard stuff like: performance monitoring, logging, exception handling” “…for error handling, to enforce architectural standards,…and for tracing and logging” Harmless advice will be useful if it can modify termination behavior of the main program Harmless advice will be useful if it can output information about the main program Fail upon violating checkPrint main program state to file Security Checks/ Policy Enforcement Tracers/Loggers/ Profilers

9 Harmless Advice Allows I/O and altered termination behavior * original value* new value original value = new value Original Program Aspect 1 Aspect 2 Program + Harmless Advice

10 System Design Source language Core language Type-directed translation Programmers use an “oblivious” source Language Core language contains explicit labels & primitive advice [based on WZL ‘03]

11 l [e]l [v] { pc.x  e adv } Core Language Aspects [WZL] l 2 [e] l 1 [e] l 4 [e] l 3 [e] l 5 [e] l 6 [e] Join Points pc = { l 1, l 3, l 6 } What? (Advice) [v/x] e adv [v/x] ( ) → * ( ) { pc.x  e adv } l  pc When? (Pointcut)

12 Harmful Advice  Advice modifies main program’s state  Advice is not harmless!! Uses reference r main Main Program Advice { pc.x  (r main := 3) }

13 Core Language Typing  How to protect main program state from interference from advice?  Protection Domains Lattice { P,  }  P is a set of protection domains   defines a partial order on P Code is executed in a protection domain   ; p ├ e :  Code executing in a low protection domain should not interfere with code executing in a high protection domain p1p1 p2p2 p4p4 p3p3    

14  How should p adv relate to the current protection domain p curr at advice triggering? Low-protection code should not interfere with high-protection code Protection Domains: Advice  types  ::= … | advice p adv  values v ::= … | { pc.x  p adv e adv }  expressions e ::= … | { e pc.x  p adv e adv }  advice e adv is executed in protection domain p adv p adv  p curr p curr  p adv e adv [v/x] ( ) e adv [v/x] ( ) l [v] triggers { pc.x  p adv e adv } p curr l [v] triggers { pc.x  p adv e adv } p curr p adv [v/x] p adv [v/x] GOOD! ( ) - OK BAD! ( )

15 Noninterference [Pottier…’03] Core Program Core Program Representation is faithful (Completeness Lemma) Differ only in low protection code Representation is faithful (Soundness Lemma) Core Value Core Value :bool Evaluation preserves noninterference invariants (Preservation Lemma) Core 2 Value :bool Represents simultaneous execution Core 2 Program :bool Must be true or false Want to Prove: Proved Non- interference

16 Language Design Source language Core language Type-directed translation Programmers use an “oblivious” source Language Core language contains explicit labels & primitive advice [based on WZL 03]

17 Source Language ProgramTranslation from Source to Core Aspect Code < Main Program (Aspect Code is in Lower Protection Domain than Main Program Code) Using Protection Domains Main Program Aspect Code 1Aspect Code 2Aspect Code 3 Main Program * original value* new value original value = new value Original Program Program + Harmless Advice Core Noninterference By Noninterference: Aspects in Source Language are Harmless Main Program Aspect Code 1 Aspect Code 2 Aspect Code 3 Programmers divide code into Main Program + Aspects

18 File System Security  Limit File Write Location & Size  Only Modify Temp Directories  Only Overwrite Tar Files Security Case Study Network Security  Limit Network Send Speed  Only Allow Certain Hosts  Soft Limit Network Send Speed Naccio Execution Monitoring System Selected Security Policies [Evans & Twyman ‘99]  Implemented “Harmless Advice” Interpreter in Standard ML Harmless Advice Is Useful for Security

19 Related Work  Classifying advice “Assistants and Observers” [Clifton... ‘02] “Observation” Advice [Rinard… ‘04] “Almost Spectative” Advice [Katz ‘04]  Aspects and Modularity “Aspectual Collaborations” [Lieberherr… ‘03] “Open Modules” [Aldrich ‘05] Information Hiding for AOP [Sullivan… ‘05] AOP and Modular Reasoning [Kiczales… ‘05]

20 Future Work  AspectML Polymorphic functional AOPL  with G. Washburn and S. Weirich Extend AspectML to allow harmless advice  Allow polymorphic protection domains  Allow mainline code programmer to specify harm level of potential advice  Separate IO into Harmless and Harmful IO Show AspectML “Java Stack-Inspection Security” is harmless

21 Conclusion  Defined a new “harmless” form of advice Harmless advice does not interfere with main program code Harmlessness is enforced by a type system for information flow control Proved a noninterference property for the language Conducted a case study demonstrating harmless advice is useful for enforcing security invariants Interpreter and Case Study at: