[cap-talk] Cap type safe OS questions

[Charles Landau]

Ben Kloosterman wrote:
>> A process in EROS or CapROS involves several objects:
>> - the "process" object, which contains thread registers, storage for
>> general-purpose capability registers, and capabilities to other objects,
>> including:
>> - an address space
>> - a capability granting authority for CPU resources,
>> - etc.
> 
> I take it this is an internal process object  to the kernel and there is a
> separate process object that is visible to the user app ( eg for something
> like a task manager list). 

There's only one process object known to the kernel. Its data is stored 
in protected kernel memory, and it is visible to the user by means of a 
capability.

The user can create whatever objects he wants to manage capabilities, 
but it would be confusing to call such an object a process.

>> In EROS and CapROS, objects are stored in kernel memory, where they are
>> protected from users. (Data pages are handled differently.) Capabilities
>> are stored in certain objects such as nodes (capability pages) or
>> processes. There are no pointers to capabilities, because they are not
>> in the user's address space.
> 
> Ok got it the app just calls the kernel and the kernel looks up whether the
> app has that capability.  

In the same way that Linux looks up whether the user process has a file 
descriptor. It's not really a "lookup", it's just a table index.

>>> Q3) User code ( including services) can't call the kernel (
>> capabilities can
>>> though I need to decide how to allow capabilities to call the kernel)
>> or
>>> have a reference outside their address space .
>> A capability is a reference to a protected object. It is not an active
>> entity that can perform calls.
> 
> Is there a design reason for this

Every active object needs a way to refer to the other objects to which 
it has access. The capability is the way to do this, and it is the 
simplest way. If a capability were an active object, the design would 
have a recursion problem, no?

> Now we have 

Are you describing your (nameless) system?

> Syscall ( method id , param fields... , string by ref) 

Unclear what the above does.

> Get capability for proc. 

Unclear where this gets the capability from.

> Invoke ( capability , methodId , paramstring) 
> 
> Isnt this the same as 
> 
> capability.MethodName(paramstring) ;
> 
> Isnt this more natural since it limits the API  also.
> 
> 
> Now since the capability can't be created by the user I can store then in
> user address space (shared memory) and use the methods as a strongly typed
> API to the underlying kernel.
> 
> Note capability.MethodName ( Type1 param1, Type2 param2 ..) 
> Calls
> 
> endPoint.SendMessage(TypedMessage message )  {..}
> 
> Note parameters can be other capabilities. 

Definitely.

> Capabilities are now not managed by the Kernel but can be managed by a
> CapabilityService ( on the same machine without further work) . 
> 
> This allows a Capability Service to run as a usermode system service instead
> of the Kernel.
> 
> 
> Good ? Bad ? 

I'm not clear what the difference is between your Kernel and this 
CapabilityService, except the name.

The Capability Service can be run anywhere as long as it's secure and 
the user has some way of calling it.