[cap-talk] Cap type safe OS questions

[Ben Kloosterman]

>
>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.

Yes , My thinking is slowly coming around here.  I was thinking UserProcess
or something to avoid the ambiguity but you right it really is some sort of
Manage ProcessCapability object.
<snip>


>>>> 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?

Its part of the Cosmos Managed Operating System Kit which I work on ( which
is a kit to build managed OS ) but will probably diverge at some point as im
not happy with the ring based security model. Also the MOSA ( Managed
Operating System Association) compiler is much better but a long way behind
so we will probably use that eventually . 

>
>> Syscall ( method id , param fields... , string by ref)
>
>Unclear what the above does.

Just represents the Coyotos syscall format eg InvokeCap


>
>> Get capability for proc.
>
As Coyotes a index lookup .
>
>> 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.

Im comparing it to traditional pure cap system. The main difference here is
the operation(methods) are on the capability rather than calling syscall and
specifying the operation and we have the option to store the capability in
the user application space ( due to the language) and do the kernel call
inside the capability.  I don't think I will go this way but just
considering it as an option. 

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

Note the Capability service does not necessarily define a service on another
machine but merely a user mode process with a separate address space. 

The big issue with such a Capability Service is the service does not have
access to the kernel address space so it would need to maintain the
Capability list  ( though the kernel would have access). I suppose this is
the same as how a scheduling services manages  scheduling though the kernel
does the actual scheduling primitives. 

This brings up the issue of  user created capabilities do these reside in
the kernel also ? If so a usermode app such as a web service could only
check a counter parties capability via a syscall or is it the case that the
kernel does all the checking and hence the rights logic needs to be part of
the kernel.


Regards, 

Ben