[cap-talk] Cap OS question

Ben Kloosterman bklooste at gmail.com
Sun Aug 2 12:36:21 EDT 2009


>
>On Sat, Aug 01, 2009 at 11:58:39AM +0800, Ben Kloosterman wrote:
>> By managed OS I mean strongly typed with Garbage collection even for
>the
>> kernel . Everything runs in the same priv ring in a shared address
>space.
>> The compiler ensures all references are valid.  Note all code is
>compiled to
>> native instructions during installation of an application.
>
>If this is true then I think it would be easiest for a capability just
>to be a normal reference to an object.  I've never used .net or C#
>(not even sure what to call the various parts), but "unsafe" pointers
>would seem to be an easy way to break this system and should be limited
>somehow.

Unsafe code will be limited eg no user apps will support it . Note CIL (
bytecode) assemblies with unsafe code on them are marked unsafe and the OS
will compile all bytecode during installation so we can choose note to
compile these ( there is also the reference checks) . The other change is
MetaData/Reflection will be limited eg no support for Emitting code ,
reading the underlying bytes or private members.

I was thinking of making Capabilies contain a reference ( which is fine if
they are stored in the kernel) but the main issues are
1) Persistence so would need to store a reference that is not a memory
address when storing on disk. 
2) How to handle the access rights and where does the logic go . In the
capability ? 



>
>In an object-capability system (as the members of this list would know
>it) the only way for things to interact are by invoking capabilities
>(i.e. calling a method on an object) and security is enforced by not
>allowing sensitive capabilities (references to objects for you) to fall
>into the "wrong" hands.
>
>Not sure how any of that relates to your understanding so far.

It all helps I was considering whether the capability should also have
methods to match the method on the named object. 
Regards,

Ben



More information about the cap-talk mailing list