[E-Lang] Confinement Tomorrow (was: My financial data)

[Mark S. Miller]

This is a sequel to 
http://www.eros-os.org/pipermail/e-lang/2001-January/004240.html , and 
addresses well the weakness explained at the end of that message.


                       In E with Auditors (not yet implemented)


Mallet would cause code defining a BobMaker to be evaluated in Harold's vat 
by means that don't involve Mallet occupying any global name space in 
Harold's vat.  (Two such means, also not yet implemented, are PassByCopy 
objects and the "meta eval" construct 
http://www.erights.org/javadoc/org/erights/e/elang/evm/Evaluator.html . 
PassByCopy is not yet implemented because it depends on auditors, so these 
two should happen at the same time.  "meta eval" may never be implemented -- 
it's not clear it's worth it.)

Unlike the pervious *.emaker story, the code Mallet needs to evaluate in 
this story may define BobMaker in a lexically nested scope, and so 
allows Mallet to parameterize the BobMaker he hands to Alice:

    /*... any lexical context, it doesn't matter ...*/
        define BobMaker ::confined {
            to new(/*... instantiation parameters ... */) :any {
                /*... instantiation-time computation ...*/
                /*... instance variable declarations ...*/
                define Bob { ... }
            }
        }

The "::<auditor-name>" clause 
http://www.erights.org/elang/kernel/Auditors.html causes the named auditor 
to be asked if the parse tree passes whatever test the auditor audits for. 
(By "parse tree", I technically mean the AST, expressed as a Minimal-XML DOM 
tree encoding the expansion of this tree to Kernel-E, according to 
http://www.erights.org/elang/kernel/index.html .) The parse tree of the 
BobMaker definition is provided to the designated auditor, together with the 
parse trees of the definition of each non-top-level variable 
http://www.erights.org/elang/kernel/DefinerPattern.html used freely within 
any of the parse trees being provided to this auditor, transitively.

The auditor-name must be bound in the top level environment in which the 
containing top-level expression is being evaluated, and must not be 
shadowed, since all auditing is done before evaluation of the top level 
containing expression begins.  If any auditor reports failure, the top level 
expression fails to load and does not begin evaluation.

The auditor named "confined" in an untampered universalScope, the default 
scope for such matters, will be, of course, the confinement auditor.  It 
need only check that all variables BobMaker uses freely lead only to 
transitively immutable state containing only non-authority granting objects. 
For this, it suffices to check that they are all defined as:

    <var-name> : final(confined)

The "final" means the variable itself is immutable 
http://www.erights.org/javadoc/org/erights/e/elib/slot/FinalSlotMaker.html . 
The "confined" argument references the very same confinement auditor, but 
this time used as a ValueGuard
http://www.erights.org/javadoc/org/erights/e/elib/slot/ValueGuard.html .  As 
a ValueGuard, the confinement auditor passes any instance of an object 
definition expression that it audited, and it also passes instances of 
various primitive types, like "integer" and "String", that the UTCB designer 
(me) has deemed rather than proved to be confined.

(If I deem mistakenly, then the whole story is corrupted, but we already 
know everyone relies on the correctness of the UTCB.  "UTCB" stands for 
"Universal TCB", and includes all the mechanism that everyone in a given vat 
necessarily relies on for their own correctness.)

Note that the variables defined within BobMaker do not need to be checked, 
as they are instantiated per invocation of BobMaker.  In this story, 
BobMaker acts as a hole-free KeyKOS Factory.  The qualifier "hole-free" is a 
weakness, not a strength, of this story compared to KeyKOS.  Unlike KeyKOS, 
Mallet has no ability to include holes he thinks Alice would find 
acceptable.  In http://www.erights.org/elib/capability/factory.html , this 
is the difference between "confinement" and "discretion" (as coined by 
Dean).  KeyKOS uniquely supports discretion.

Given a capability communication channel between Mallet and Alice, which 
would naturally occur if Alice were contracting with Mallet for this service 
within the system, Mallet, after instantiating a BobMaker, could give it 
to Alice directly without Mallet and Alice ever needing to share a namespace:

    farFacetOfAlice <- useThisToMakeBob(FarBobMaker )

farFacetOfAlice is far from Mallet because it's on Alice's machine.  
FarBobMaker is far because it's on Harold's machine.

In the previous story, Alice required prior access to the 
"import__uriGetter" of Harold's vat.  Here, she needs prior access to the 
"confined" auditor of Harold's vat, which she'll name "farConfined" and use 
only as a ValueGuard.

The useThisToMakeBob() method within a facet of Alice could proceed as follows:

    to useThisToMakeBob(FarBobMaker) {

FarBobMaker is also far from Alice, since it's on Harold's machine.

        FarBobMaker := farConfined <- coerce(FarBobMaker, null)

Her FarBobMaker variable now holds a promise which will either

* resolve to a reference to a remote object, which farConfined is 
guaranteeing is transitively immutable and non-authority granting 
(presumably the same object as that sent to Alice by Mallet, but at least a 
valid coercion of that object), or

* resolve to a broken reference, if the coerce method instead throws an 
exception, or if a network partition breaks anything along the way.

Of course, to make use of message pipelining 
http://www.erights.org/elib/concurrency/pipeline.html , she doesn't need to 
wait for this resolution, but can instead proceed "assuming" successful 
resolution:

    define FarBob := FarBobMaker <- new(/*...access to Alice's data...*/)
    ... (FarBob <- getBalance) ...

Should the coerced FarBobMaker resolve to broken, then 
broken-promise-contagion, like NaN contagion, will cause FarBob to resolve 
to broken and all FarBob's answers to resolve to broken.  Should she want to 
determine whether the coercion was successful before taking some further 
action, she'd use a when-catch 
http://www.skyhunter.com/marcs/ewalnut.html#SEC38 .

Crucially, even if the original FarBobMaker provided by Mallet doesn't pass 
Harold's confinement auditor, none of the messages Alice sends on the 
resulting not-yet-broken promises can be intercepted by Mallet, even if 
Mallet has tampered with his E implementation, as they are promises for the 
result of a request to Harold's auditor on Harold's machine, or promises for 
the results of requests to such promises, and will therefore only be 
optimistically sent to Harold's machine, not Mallet's, and sent only on the 
Alice-Harold connection.

Although this is a distributed use of confinement, and so goes well beyond 
what's currently achievable in KeyKOS or EROS, it is still well short of 
distributed confinement 
http://www.erights.org/elib/capability/dist-confine.html , which would seem 
to require support for discretion.


                   What is Wrong With All These Pictures


A weakness with all these stories is that none of the systems described 
claim to be able to fully prevent outward leakage of bits through wall 
banging.  They can fully confine authority but not bits.  Since Alice's 
financial data is bits, none of these stories can actually give Alice the 
assurance she needs.

KeyKOS and EROS implementations claim to be able to limit the bandwidth of 
wall-banging, and this may or may not be sufficient for Alice.  The 
engineering effort required to limit the bandwidth may be reasonable when 
one is running on the bare metal, as an OS does.  It does not look 
reasonable when one is standing on sand beyond anyone's ability to 
comprehend, as with E running on Java running on Windows. Therefore, E makes 
no claims whatsoever to limit the bandwidth of wall-banging.  An individual 
E implementation running on a well behaved platform (such as ENative 
http://www.erights.org/enative/index.html on EROS) may be able to make such 
claims.  It may even be able to live up to them!

OTOH, E is uniquely able to prevent the inward leakage of bits (wall 
listening) through deterministically replayable computation.  KeyKOS & EROS 
cannot force computation to be deterministically replayable, because no 
capability is needed to allow a domain to do a FORK/SEND, and these in turn 
produce (in Actors terminology) arrival order non-determinism.  This would 
seem a sufficient covert channel to allow a graph of domains to wall-listen.

In KeyKOS & EROS, Bob and Mallet have a bandwidth-limited full duplex 
channel.  In future E, Bob has a not-necessarily-limited channel out to 
Mallet, but no channel back.  It's not clear which kind of assurance will 
usually be preferred by Alice.

        Cheers,
        --MarkM