[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] Summer of Code
From:       "Ben Laurie" <benl () google ! com>
Date:       2007-02-27 10:37:25
Message-ID: 1b587cab0702270237n634e8a86h9a98ff6bf8be1daa () mail ! gmail ! com
[Download RAW message or body]

On 2/26/07, James A. Donald <jamesd@echeque.com> wrote:
> Kevin Reid wrote:
> > On Feb 26, 2007, at 14:33, Mark Seaborn wrote:
> >> Would you want a Python implementation of E's Pluribus protocol?  (Is
> >> it still called Pluribus or is it called CapTP?)
> >
> > If I understand correctly, Pluribus is CapTP + VatTP.
> >
> > VatTP is the encryption/vat-identity component, and CapTP is the
> > distributed reference component.
> >
> > MarkM once told me [approximately] that CapTP is sufficiently complex
> > that he considered it a better idea to write an E implementation and
> > run (the as yet unwritten) CapTP-in-E on it than to reimplement CapTP
> > in other languages.
>
> An interpreted language can be easily sandboxed, since the interpreter
> stands between the source code and every access to the machine.  So it
> is easy to do capabilities and suchlike in interpreters.

You would like to think that, however, having attempted this for both
Perl and Python I can tell you it ain't so.

The reason is that most modern interpreted languages are actually
semicompiled, and by the time they hit the interpreter they've lost
the information needed to enforce capability discipline.

>
> However, interpreted languages are always slow and inefficient.  I keep
> hearing people tell me that Java with JITC has only x% overhead, where x
> is a quite small number, yet I notice a striking difference in the
> performance of similar applications, where one is implemented in Java,
> and the other in C++.  Furthermore there is a great deal of open source
> and public domain C code around.
>
> The primary area where interpreted languages are useful is where only a
> small number of copies of the program will ever be used, when, for
> example, one is writing code for one particular web site, in which
> situation programmer resources are vastly more limited and important
> than machine resources.
>
> So we really do need a cap based VM environment that runs ELF files
> (Executable and Linking Format files), though I realize this is a rather
>   huge amount of work.  To get it done, really needs funding, perhaps by
> some deep pockets organization with a real need for a secure operating
> system.
>
> Such a system can live within existing operating systems, and, over
> time, increasing amounts of code are executed within the capabilities
> system, and only old code, (therefore code that is likely to be somewhat
> trustworthy) is run within the outer operating system.
>
> The OLTP operating system, bifrost, where everything runs in chrooted vm
> sandbox, is a big step in this direction, but it is still chrooted linux
> for compatibility with existing code, therefore fundamentally
> permissions based, not capabilities based.
>
>
>
>
>
>
>
> >
>
> _______________________________________________
> cap-talk mailing list
> cap-talk@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]