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
2
Aspect-Oriented Programming
Join Points

When? (Pointcut)

What? (Advice)
Added Functionality (Logging)
Aspect = Pointcuts + Advice + State
3
AOP Advantages
Logging
Advice
 Easy
No “Scattering”
“Tangling”
Consistency

Checking
To audit
understand
added added
original
logginglogging
functionality,
code for
examine mainline
functionality,
consistency,
simply
examine
code
analyze
logging
pointcut
advice
only triggers logging advice
that
4
But Beware!
Advice
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

5
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
6
What
is harmless advice?
Contributions

Defined
a new “harmless” form of advice
 What does that mean?
Harmless advice does not interfere with main
program code
A spectrum
of “interfering” effects:
 Doing
Harmlessness
enforced
by a type system for

work of anyiskind
(alters timing)
flow
 information
Looping or early
exitcontrol
(alters termination)

file (alters observations
of thefor
file the
system)
 Writing
Provedtoaanoninterference
property
 Writing
to a mutable mainline data structure
language
Criteria
impacting
ourstudy
choice:
 Conducted
a case
demonstrating harmless
 Must
help
programmers
preserve
local reasoning
advice
isAOP
useful
for enforcing
security
invariants





about main program code
Must be enforceable
Must admit common AOP applications
7
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”
Security
Checks/
 Tracers/Loggers/
“…And the standard stuff like:
performance
monitoring,
handling”
Profilerslogging, exception
Policy Enforcement
 “…for
error handling,
enforce
architectural
Print
main program
state to file to
Fail
upon violating
check
standards,…and for tracing and logging”

Harmless advice will be useful if
it can output information
about the main program
Harmless advice will be useful
if it can modify termination
behavior of the main
program
8
Harmless Advice
Original Program
Program +
Harmless Advice
Aspect 1
Aspect 2
* original value
* new value
original value = new value
Allows I/O and altered termination behavior
9
System Design
Programmers use an
“oblivious” source
Language
Source language
Type-directed
translation
Core language
Core language
contains explicit
labels & primitive advice
[based on WZL ‘03]
10
Core Language Aspects
[WZL]
Join Points
When? (Pointcut)
pc = { l1, l3, l6 }
l1[e]
l2[e]
l4[e]
l3[e]
What? (Advice)
{ pc.x  eadv }
l5[e]
l [v]
[e]
[v/x]
l6[e]
()
eadv [v/x] →* ( )
{ pc.x  eadv }
l  pc
11
Harmful Advice
Uses reference rmain
{ pc.x  (rmain := 3) }
Main Program
Advice

Advice modifies main program’s state

Advice is not harmless!!
12
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
13
Protection Domains: Advice
 ::= … | advicepadv
 values
v ::= … | { pc.x padv eadv }
ppcurr
pcurr  padve ::= … | {peadv
 expressions
adv eadv }
pc.x

types
l
[v]
triggers
padv in protection domain
pcurr
eadv([v/x]
 advice
e)adv is executed
{ pc.x padv eadv }
padv

()
[v/x]
[v/x]
( ) - OK
How
l [v] should
triggerspadv relate to the current
pcurr
padv
) triggering?
protection
domain
pcurr at eadvice
adv([v/x]
{ pc.x p e }

adv
adv
Low-protection code should not interfere with
high-protection code
BAD!
GOOD!
14
Noninterference
Want to Prove:
Representation
is faithful
(Completeness Lemma)
Representation
is faithful
(Soundness Lemma)
Core
Program
[Pottier…’03]
Core
Program :bool
Differ only in low
protection code
Represents simultaneous
execution
Core 2
:bool
Core Program Core
Value
Value :boolEvaluation preserves
noninterference invariants
(Preservation Lemma)
Core 2
Value :bool
Must be true or false
Proved Noninterference
15
Language Design
Programmers use an
“oblivious” source
Language
Source language
Type-directed
translation
Core language
Core language
contains explicit
labels & primitive advice
[based on WZL 03]
16
Using Protection Domains
Core
Source
Translation
Noninterference
Language
from Source
Program
to Core
Original
Program
Main Program
Program +
Harmless Advice
Main Program
Aspect Code 1
Main Program
Aspect Code 2
Aspect Code 1
Aspect Code 2
* original value
Aspect Code 3
* new value
Aspect
Code
<
Main
Program
divide code into
ByProgrammers
Noninterference:
(Aspect
is in
Protection
MainCode
Program
+ Aspects
original
value
= Lower
new
value
Domain
than Main
Program
Aspects
in Source
Language
are Code)
Harmless
17
Security Case Study

Implemented “Harmless Advice” Interpreter in
Standard ML
Naccio Execution Monitoring System
Selected Security Policies
[Evans & Twyman ‘99]
File System Security
Network Security
 Limit File Write Location &
 Limit Network Send Speed
 Only Allow Certain Hosts
 Soft Limit Network Send
Size
 Only Modify Temp Directories
 Only Overwrite Tar Files
Speed
Harmless Advice Is Useful for Security
18
Related Work

Classifying advice




“Assistants and Observers”
“Observation” Advice
“Almost Spectative” Advice
[Clifton... ‘02]
[Rinard… ‘04]
[Katz ‘04]
Aspects and Modularity




“Aspectual Collaborations”
“Open Modules”
Information Hiding for AOP
AOP and Modular Reasoning
[Lieberherr… ‘03]
[Aldrich ‘05]
[Sullivan… ‘05]
[Kiczales… ‘05]
19
Future Work

AspectML

Polymorphic functional AOPL


Extend AspectML to allow harmless advice




with G. Washburn and S. Weirich
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
20
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/
21