[cap-talk] C-like Capability language

Mike Samuel mikesamuel at gmail.com
Thu Jul 31 18:00:18 CDT 2008


2008/7/31 William Pearson <wil.pearson at gmail.com>

> Some people may remember me from my previous post. Quick recap I want
> to do capability based security in a VM designed for real-time systems
> which uses an agoric system to allocate system resources. This uses a
> judge (generally human, potentially automated) that distributes credit
> to the programs that do well to allow them to buy the computational
> resources, rather than using real money.  So that the system would
> come to be controlled by programs that do whatever the judge valued.
> Also I am interested in allowing mobile code down to the
> scheduler/device driver level, so a bit further down than the classic
> agoric system.
>
> As such I am trying to design a C-like language, fairly low level but
> abstracting a few things away. Basically the syntax would be C
> (structs and all), with added syntax to deal with capabilities and
> domains. So not an object capability model, but it still might be
> interesting.
>
> There would be also be an assembler code that could be inlined for
> very low level stuff. The VM would enforce all the capabilities. The
> language constructs would just be to make it explicit.
>
> domain d;
> //All code compiled after this declaration before another such
> declaration would be considered in the same domain. It has no meaning
> between compilations, you can't compile domains seperately
>
> typedef struct bank
> {
>  int cash;
>  int * array;
> } struct;
>
> bank mybank;
> mybank.array = malloc(8*sizeof(int));
> int temp;
> bank% bankcap= @bank;
> // % specifies this is a capability to a bank (leaving it in a
> specially defined NULL harmless state if undefined)
> // @ creates a capability to an existing object in the same way that &
> gets a pointer (under the hood it would create a read only capability,
> with a length equal to the sizeof bank )
>
> bankcap-]cash = 0;
> // -] acts as the -> operator in C but for capabilities. This would
> cause an error as by default capabilities to structs are read only,
> capabilities to function execute only etc.
> int temp = bankcap-]array[1] ;
> // also not allowed as it is implicitly dereferencing a pointer;
>
>
> rescind(bankcap.lock, bankcap.key)
> // capabilities would have two parts locks and keys. Keys would be the
> part duplicated and passed around. You can also have multiple locks
> for the same object. This functions would mean that the key would no
> longer be valid for the lock. If you create two capabilities to the
> same function they would have different locks and keys, if you copy a
> capability it would get the same lock and a copy of the key. This
> allows the lock to be changed, so the key is no longer valid.
>
> There will be lots of functions that programs can only use on
> capabilities with locks defined in their own domain.
>
> Has something similar been done before (a google of cap-talk suggested
> some thought had been put into it for EROS), and does anyone have any
> better ideas for syntax other than slavishly copying the C syntax?
>

Maybe start with a safe language like Cyclone instead.
>From http://cyclone.thelanguage.org/

*Cyclone is like C*: it has pointers and pointer arithmetic, structs,
arrays, goto, manual memory management, and C's preprocessor and syntax.

*Cyclone adds features* such as pattern matching, algebraic datatypes,
exceptions, region-based memory management, and optional garbage collection.

*Cyclone is safe*: pure Cyclone programs are not vulnerable to a wide class
of bugs that plague C programs: buffer overflows, format string attacks,
double free bugs, dangling pointer accesses, etc.







>
>  Will Pearson
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080731/d7877b89/attachment.html 


More information about the cap-talk mailing list