[E-Lang] Opening Objects (was: E questions)

[Mark S. Miller]

At 08:03 AM Wednesday 7/18/01, Mark Seaborn wrote:
>"Mark S. Miller" <markm@caplet.com> writes:
>[snip]
>> We have not yet designed what the protocol is of the can opener, the
>> means of building an object to be openable by one, nor the synergy
>> protocol by which a can opener opens (or fails to open) a candidate
>> object.  Suggestions appreciated!
>
>I have been thinking about something related in OCaml.  I wanted to be
>able to brand closures so that anyone who holds the brand can extract
>hidden values from closures they branded.  It should be possible to do
>this branding at a low level by copying the physical closure and
>adding a couple of words to the end.  The closure's function should
>not care about the extra words, and if one of those words is for a
>secret held by the brand, no closure could capture those values and be
>mistaken for a branded closure.  (I have not implemented this yet.  I
>decided to just put closures in wrappers that could have hidden values
>extracted using brands -- something more like using sealer/unsealer
>pairs with an unhidden part.)
>
>The relevance of this to E is that it would be simple and efficient
>and would not require changing the representation of closures.  It
>only requires two trusted operations on closures.  Objects do not need
>to be born branded, but can be created and then branded.  This means
>that the branded object would not be equal to its unbranded
>counterpart, and that makes this approach subtly different from one in
>which the brand keeps a weak hash table of all the objects it
>considers branded.


There are two things you might mean by "trusted operation" here.  1) An 
operation whose implementation is trusted (which these certainly would need 
to be), or 2) an operation that can only be invoked by trusted code.  For 
"trusted", I will assume you mean "universally trusted", and thereby part of 
the UTCB.  (Code that everything in a vat is vulnerable to / at the mercy of 
/ relies upon.)

Note that #2 implies #1.  For #2, I will use the KeyKOS term "closely held". 
Operations which are closely held are not, to my mind part of the UTCB's 
public interface.  Operations in category #1 but not #2 are in the UTCB's 
public interface, and the UTCB's public interface consists of the set of 
such operations.  These I will call "UTCB exported operations". (After all 
these years, it's shameful that we're all still groping for good terminology 
for these distinctions.)

If you propose these operation be closely held, that sounds like a fine 
implementation technique within the UTCB, but we still need to figure out 
what operations the UTCB should export for accessing the resulting 
functionality.

If you propose these operations to be exported by the UTCB, then I'm 
confused.  An unbranded object should still be encapsulated.  Since it's 
unbranded, it has no record of who should be able to open it, so it should 
be encapsulated from everyone (or, to allow conventional debugging as well 
as acknowledge reality, from everyone outside their own UTCB).  If I could 
use your branding operation to make a copy of this object branded with my 
brand, and if I could then open this copy, I would discover what the state 
of the original object is (or was at the time I made the copy, depending on 
what was copied).  This ability to read a copy of the state of an 
encapsulated object fatally breaks security.


        Cheers,
        --MarkM