1 / 21

Harmless Advice

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.

muriel
Télécharger la présentation

Harmless Advice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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) Join Points Added Functionality (Logging) Aspect = Pointcuts + Advice + State

  4. 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

  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 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

  9. 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

  10. 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

  11. 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

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

  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 p1   p2 p3   p4

  14. 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!

  15. 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

  16. 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

  17. 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

  18. 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

  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: http://www.cs.princeton.edu/sip/projects/aspectml/

More Related