[e-lang] E research topics

zooko at zooko.com zooko at zooko.com
Fri Apr 13 13:15:37 CDT 2007

 I, Zooko, wrote the lines prepended with "> > ".
 Kevin Reid wrote the lines prepended with "> ".
> > So my wish is that someone invent a way to securely re-use native  
> > code libraries in E applications.  (Or perhaps Emily -- I don't  
> > know much about Emily yet.)
> What exactly do you mean by "securely"? How do you propose to  
> restrict it?

I mean that the library that I'm re-using does not get authority that I didn't
explicitly grant it, including authority to modify my persistent state
(filesystem), connect to the network, read or write the non-granted state of my
program (i.e. memory safety), etc..

There are several things that make this easier than "impossible":

1.  I don't require that I am able to grant authorities to the library with
optimal ease, transparency, or efficiency.

At least as a first cut, I might be limited to using the library only in a sort
of "batch mode", granting it a set of authorities, letting it run to
completion, and then reading back in its results.  Obviously this process is
already possible, and making it easier, more transparent, and more efficient
would be a primary contribution of such research.

2.  As a first cut I don't require that I have defensive liveness against the
re-used library, only defensive consistency.  That is: I don't require defense
against a denial-of-service attack by of the library, such as by going into an
infinite loop, or such as by bogging down my operating system by over-using

3.  I don't require that the re-used library be constrained from receiving or
emitting information through covert channels.

These caveats open the door to the kind of hack that you suggest:

> In principle, it should be straightforward for E-on-CL to use an  
> existing FFI to talk to C-style native code, but same-process may not  
> count as "secure".

It wouldn't, because the library would be able to violate memory-safety and
thus violate consistency of the E code.  However, if the native code were
running in a separate process, communicating with the E code through an IPC
mechanism, then we'd be getting close...



More information about the e-lang mailing list