Harmless Advice∗
Total Page:16
File Type:pdf, Size:1020Kb
Harmless Advice ∗ Daniel S. Dantas David Walker Princeton University Princeton University [email protected] [email protected] Abstract number of calls to each method: The what in this case is the com- when This paper defines an object-oriented language with harmless putation that does the recording and the is the instant of time aspect-oriented advice. A piece of harmless advice is a compu- just prior to execution of each method body. In aspect-oriented ter- what advice tation that, like ordinary aspect-oriented advice, executes when minology, the specification of to do is called and the when pointcut control reaches a designated control-flow point. However, unlike specification of to do it is called a . A collection of ordinary advice, harmless advice is designed to obey a weak non- pointcuts and advice organized to perform a coherent task is called aspect interference property. Harmless advice may change the termination an . behavior of computations and use I/O, but it does not otherwise in- Many within the AOP community adhere to the tenet that as- oblivious fluence the final result of the mainline code. The benefit of harmless pects are most effective when the code they advise is to advice is that it facilitates local reasoning about program behavior. their presence [11]. In other words, aspects are effective when a More specifically, programmers may ignore harmless advice when programmer is not required to annotate the advised code (hence- mainline code reasoning about the partial correctness properties of their programs. forth, the ) in any particular way. When aspect- In addition, programmers may add new pieces of harmless advice oriented languages are oblivious, all control over when advice to pre-existing programs in typical “after-the-fact” aspect-oriented is applied rests with the aspect programmer as opposed to the style without fear they will break important data invariants used by mainline programmer. This design choice simplifies after-the-fact the mainline code. customization or analysis of programs using aspects. For exam- In order to detect and enforce harmlessness, the paper defines ple, obliviousness makes it trivial to implement and update an ex- a novel type and effect system related to information-flow type tremely flexible profiling infrastructure. To adjust the places where systems. The central technical result is that well-typed harmless profiling occurs, which might be scattered across the code base, advice does not interfere with the mainline computation. The paper one need only make local changes to a single aspect. Oblivious- also presents an implementation of the language and a case study ness might be one of the reasons that aspect-oriented programming using harmless advice to implement security policies. has caught on with such enthusiasm in recent years, causing major companies such as IBM and Microsoft to endorse the new paradigm Categories and Subject Descriptors D.3.1 [Programming Lan- and inspiring academics to create conferences and workshops to guages]: Formal Definitions and Theory study the idea. On the other hand, obliviousness threatens conventional mod- General Terms Design, Experimentation, Security, Languages, ularity principles and undermines a programmer's ability to rea- Theory son locally about the behavior of their code. Consequently, many Keywords Aspect-oriented, Harmless Advice, Aspects, Noninter- traditional programming language researchers believe that aspect- ference oriented programs are ticking time bombs, which, if widely de- ployed, are bound to cause the software industry irreparable harm. One central problem is that while mainline code may be syntacti- 1. Introduction cally oblivious to aspects, it is not semantically oblivious to aspects. Aspect-oriented programming languages (AOPL) such as AspectJ Aspects can reach inside modules, influence the behavior of local [17] allow programmers to specify both what computation to per- routines, and alter local data structures. As a result, to understand form as well as when to perform it. For example, AspectJ makes it the semantics of code in an aspect-oriented language such as As- easy to implement a profiler that records statistics concerning the pectJ, programmers will have to examine all external aspects that might modify local data structures or control flow. As the number ∗ This research was supported in part by ARDA Grant no. NBCHC030106, and invasiveness of aspects grows, understanding and maintaining NSF grants CCR-0238328 and CCR-0208601, and an Alfred P. Sloan Fel- their programs may become more and more difficult. lowship. Opinions, findings, conclusions, and recommendations expressed In this work, we define a new form of harmless aspect-oriented throughout this work are not necessarily the views of the NSF, ARDA or advice that programmers can use to accomplish nontrivial program- Sloan foundation and no official endorsement should be inferred. ming tasks yet also allows them to enjoy most of the local reasoning principles they have come to depend upon for program understand- ing, development, and maintenance. Like ordinary aspect-oriented advice, harmless advice is a computation that executes whenever Permission to make digital or hard copies of all or part of this work for personal or mainline control reaches a designated control-flow point. Unlike classroom use is granted without fee provided that copies are not made or distributed ordinary aspect-oriented advice, harmless advice is constrained to for profit or commercial advantage and that copies bear this notice and the full citation prevent it from interfering with the underlying computation. There- on the first page. To copy otherwise, to republish, to post on servers or to redistribute fore, harmless advice can be added to a program at any point in the to lists, requires prior specific permission and/or a fee. development cycle without fear that important program invariants POPL'06 January 11–13, 2006, Charleston, South Carolina, USA. Copyright c 2006 ACM 1-59593-027-2/06/0001. $5.00. will be disrupted. In addition, programmers who develop, debug, or enhance mainline code can safely ignore harmless advice, if there for such “harmless” tasks as enforcing consistency in tracing and is any present. logging concerns and for encapsulating monitoring and statistics In principle, one could devise many variants of harmless advice components. We also observed a sequence of emails on the AspectJ depending upon exactly what it means to interfere with the under- users list [13] cataloging uses of aspects with Java projects. Many lying computation. At the most extreme end, changing the timing respondents specified that, in addition to some uncommon uses behavior of a program constitutes interference and consequently, that they wished to highlight, they certainly used AspectJ for the only trivial advice is harmless. A slightly less extreme viewpoint is common aspect-oriented concerns such as profiling, security, and one taken by secure programming languages such as Jif [23] and monitoring mentioned above. Finally, we have done a case study Flow Caml [25]. These languages ignore some kinds of interfer- in security, rewriting the security policies from Evans' thesis [9] in ence such as changes to the timing and termination behavior of our system, and finding that all but one were harmless. programs, arguing that these kinds of interference will have a min- In the rest of this paper, we develop a theory of harmless advice imal impact on security. However, overall, they continue to place following the same strategy as used in previous work by Walker, very restrictive constraints on programs, prohibiting I/O in high se- Zdancewic, and Ligatti [30] (hereafter referred to as WZL) and in- curity contexts, for instance. Allowing unchecked I/O would make spired by the type-theoretic definition of Standard ML [12]. This it possible to leak secret information at too great a rate. strategy involves defining type-safe languages at two levels of ab- In our case, an appropriate balance point between usability straction: a high-level, user-friendly source language for program- and interference prevention is even more relaxed than in secure mers and a lower-level semantic intermediate language we call the information-flow systems. We say that computation A does not in- core calculus. The core calculus consists of a collection of sim- terfere with computation B if A does not influence the final value ple, orthogonal constructs amenable to formal analysis. The source produced by B. Computation A may change the timing and termi- language is defined by translation into the core calculus. The pri- nation behavior of B (influencing whether or not B does indeed mary reason for this structure is that the source language features return a value) and it may perform I/O. are quite complex—a direct analysis of a deep property such as Now suppose that A is advice and B is the main program. If noninterference would be incredibly difficult and error-prone. We we can establish that A does not interfere with B as defined above, simplify the situation by proving a collection of powerful proper- programmers working on B can reason completely locally about ties of the core calculus. Then, we show that the translation from partial correctness properties of their code. For these properties, source into core is type-preserving and exploit properties of well- they do not need to know anything about advice A or whether or typed core calculus constructs to obtain properties of the source. not it has been applied to their code. For example, if we are work- Overall, this structure helps modularize and simplify an otherwise ing in a functional language like ML and enjoy equational rea- daunting task. soning, all our favorite (partial correctness) equations continue to Section 2 defines the core calculus. The calculus contains primi- hold. If we are working in an imperative language and reason (per- tive notions of pointcuts, advice and a collection of static protection haps informally) using Hoare logic-style pre- and post-conditions, domains, arranged in a partial order.