[cap-talk] Cap OS question

[Ben Kloosterman]

Hi Toby , 

"You might consider adopting Sam's suggestion that you allow any object
reference in C# to be a capability that simply refers to the object being
referenced. You might need to outlaw some of the C# features in the way that
Joe-E does for Java in order to ensure that the rules for how object
references propagate match the rules for capability-propagation."

Which C# features will hinder this ? ( Obviously unmanaged code is
restricted)  Note there are also compiler checks as a backup to ensure no
direct or incorrect memory references eg all calls and jumps are patched by
the dynamic loader. Also interested in Java features that would cause an
issue when the OS compiler compiles the byte code. 

Really trying to find a capability security system that will work with
compiled Java Byte Code and Compiled CIL ( C# etc) noting we control the
compiler and dynamic loader. Getting a non C capable OS of the ground is
hard enough with Java and .NET capability at least you can run a lot of apps
without change. Sure from a security or Research point of views this will be
inferior but I think it is possible with .NET apps anyway (and maybe Java)
as the Runtime provides so much and can be controlled.

I did have an idea of using a reference to an interfaces as the type of the
object capability but this doesn't work as you can cast it back to the
object hence am using wrapper objects for the rights.

At the moment I have 2 types of Object capabilities. 

Class1 is a simple reference to an OS object. 
Class2 is a reference to a wrapper object which contains a subset of
functions to allows different functionality eg 

Ref - > ReadFile  -> File  .

A nice bonus of this is File can be dynamically loaded or even static ( but
also needs an internal constructor) .


In all cases the actual objects are managed by the appropriate application
(service)  , not the kernel and uses internal constructors so cannot be
instantiated outside of the service. Public Members are visible and can be
invoked internal ones cannot.

I have also removed the concept of each applications having its own software
enforced memory region after talking with Andreas , basically each thread
has an Allocator which is used so memory allocations are close by ( for
cache coherency) but otherwise it is a single address space. Also there is
no context switch I have used the old task switch term. 

Over the next few weeks I will draw up a more detailed design. 

Regards, 

Ben