[e-lang] E auditing framework

[Mark S. Miller]

Stephan van Staden wrote:
> Regarding auditors and auditing in E, what would an "openly extensible 
> static auditing framework" entail? What background material would be 
> relevant in the design and construction of one (e.g. use cases, papers, 
> ...)?


All auditing proposals start by providing the auditor with some standardized 
AST representation of the object definition expression to be audited. They 
differ regarding how the auditor may obtain relevant information about the 
constraints on the instance (free) variables of the object being audited.

* In <http://www.erights.org/elang/kernel/auditors/>, the auditor was provided 
with the ASTs of the patterns defining these variables, and so on for the 
variables used freely by these ASTs, etc. Kevin rightly objected that this was 
too difficult and error prone for practical use.

* The E-on-CL auditing system, which is the only working one we have, provides 
the auditors with direct access to the values of these variables. This is the 
most straightforward and usable, but 1) violates POLA (the auditor can invoke 
these values), and 2) makes it hard to memoize auditing decisions. We 
currently have an untested belief that such memoization is necessary for 
auditing to be affordable.

In some sense, the above two attempts are at opposite extremes, and have 
opposite flaws and virtues. The current E-on-Java sources have made some 
partial progress towards an intermediate position:

* For each free variable, inform the auditor 1) whether the variable is 
defined as "final", "var", or "slot", and 2) if the variable definition is 
guarded, provide the auditor with the value of this guard (i.e., the value 
that the pattern's guard expression evaluated to). Given that guards and 
auditors are both themselves constrained to be DeepFrozen, this would 
guarantee that such access does not provide the auditor any authority. Given 
that guard values tend to be much more stable than the values they guard, this 
would lead to better opportunities for memoization.

Starting from such a runtime-only optimization story, one could profitably add 
many static or semi-static optimizations.

* Alternatively, the auditor, instead of asking for either variable values or 
guard values, could ask instead "does free variable 'x' pass guard G?", for a 
guard value G provided by the auditor. Then the auditing framework could 
decide based on either the variable's value or the variable's guard, but could 
memoize in either case.


-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM