[cap-talk] C-like Capability language
wil.pearson at gmail.com
Sat Aug 2 03:47:51 CDT 2008
2008/8/1 Jonathan S. Shapiro <shap at eros-os.com>:
> On Fri, 2008-08-01 at 00:13 +0100, Toby Murray wrote:
>> On Thu, 2008-07-31 at 16:00 -0700, Mike Samuel wrote:
>> > 2008/7/31 William Pearson <wil.pearson at gmail.com>
>> > I want to do capability based security in a VM
> It isn't clear why you want to do this. In a type-safe VM, object
> references already *are* capabilities (unless the underlying VM
> specification is badly broken). As "proof by example", look at things
> like Joe-E or E.
> What do you anticipate will be true about capabilities in your language
> that is not true of object references more generally?
The capabilities themselves, nothing. I'm interested in the
compiler/interpreter life cycle (and other programs that deal with
programs e.g. apt-get). High level languages you tend to want to
change, to improve compilation or interpretation speed or add new
features/syntactic sugar. So now you have two choices implement E
version x+1 on java or implement E vX+1 on E v1. If you go down the
java route you get people used to installing new java programs, Eve
can come along and fork E, to FastE which also sends sensitive info
about the programs you run to Eve. Which is not the way to go.
Implementing E vX+1 on EvX would be weird. You would be stuck with any
flaws of E v X and would always have to write new E interpreters in
it, unless you wanted to have two levels of indirection.
So a lowish level bytecode VM that enforced capabilities and was high
level language agnostic, that you wouldn't want to change very often,
is the way I am going. Then you would compile your each version of
your compiler/interpreter down to this language, and you would have
control over what it did.
More information about the cap-talk