210 likes | 299 Views
Harmless Advice. Daniel S Dantas Princeton University with Prof. David Walker. Aspect-Oriented Programming. Large Program. Want to add a new logging feature that references many parts of the program. Aspect-Oriented Programming. When? (Pointcut) What? (Advice). Join Points.
E N D
Harmless Advice Daniel S Dantas Princeton University with Prof. David Walker
Aspect-Oriented Programming Large Program Want to add a new logging feature that references many parts of the program
Aspect-Oriented Programming • When? (Pointcut) • What? (Advice) Join Points Added Functionality (Logging) Aspect = Pointcuts + Advice + State
AOP Advantages • No “Tangling” • To understand original functionality, examine mainline code Logging Advice • 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
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
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
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
What Are Aspects Used For? • AspectJ Users Email 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” Tracers/Loggers/ Profilers Security Checks/ Policy Enforcement Print main program state to file Fail upon violating check 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
Harmless Advice Program + Harmless Advice Original Program Allows I/O and altered termination behavior Aspect 1 Aspect 2 * original value * new value original value = new value
System Design Programmers use an “oblivious” source Language Source language Type-directed translation Core language contains explicit labels & primitive advice [based on WZL ‘03] Core language
Core Language Aspects [WZL] Join Points l1[e] When? (Pointcut) l2[e] pc = { l1, l3, l6} l4[e] l3[e] What? (Advice) l6[e] { pc.x eadv } l5[e] ( ) l [v] l [e] →* ( ) eadv [v/x] [v/x] { pc.x eadv } l pc
Harmful Advice • Advice modifies main program’s state • Advice is not harmless!! Uses referencermain { pc.x (rmain := 3) } Main Program Advice
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 p1 p2 p3 p4
Protection Domains: Advice • types ::= … | advicepadv • values v ::= … | { pc.x padv eadv } • expressions e ::=… | { epc.x padv eadv } • adviceeadvis executed in protection domainpadv padv pcurr pcurr padv l [v]triggers { pc.x padv eadv } eadv[v/x] ( ) padv pcurr ( ) [v/x] [v/x] ( ) - OK l [v] triggers { pc.x padv eadv } eadv[v/x] ( ) • How should padv relate to the current protection domain pcurr at advice triggering? • Low-protection code should not interfere with high-protection code pcurr padv GOOD! BAD!
Core Value Core Value :bool Noninterference [Pottier…’03] Want to Prove: Differ only in low protection code Core Program Core Program :bool Representation is faithful (Completeness Lemma) Represents simultaneous execution Core 2 Program :bool Evaluation preserves noninterference invariants (Preservation Lemma) Core 2 Value :bool Representation is faithful (Soundness Lemma) Must be true or false Proved Non- interference
Language Design Programmers use an “oblivious” source Language Source language Type-directed translation Core language contains explicit labels & primitive advice [based on WZL 03] Core language
Main Program Aspect Code 1 Aspect Code 2 Aspect Code 3 Using Protection Domains Source Language Program Translation from Source to Core Core Noninterference Program + Harmless Advice Original Program Main Program Aspect Code 1 Main Program Aspect Code 2 Aspect Code 3 * original value * new value Aspect Code < Main Program (Aspect Code is in Lower Protection Domain than Main Program Code) Programmers divide code into Main Program + Aspects By Noninterference: original value = new value Aspects in Source Language are Harmless
Security Case Study • Implemented “Harmless Advice” Interpreter in Standard ML Naccio Execution Monitoring System Selected Security Policies [Evans & Twyman ‘99] File System Security Limit File Write Location & Size Only Modify Temp Directories Only Overwrite Tar Files Network Security Limit Network Send Speed Only Allow Certain Hosts Soft Limit Network Send Speed Harmless Advice Is Useful for Security
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]
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
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: http://www.cs.princeton.edu/sip/projects/aspectml/