[cap-talk] Cap type safe OS questions

Ben Kloosterman bklooste at gmail.com
Sun Aug 2 03:48:39 EDT 2009


Thx for the reply , Comments inline

>On CapROS-devel, Ben Kloosterman wrote:
> > Charles Landau wrote:
>>> I would also ask you to clarify the questions considerably. Remember,
>>> >not everyone comes with the background that you may be taking for
>>> >granted. For example, when you say "the design" or "managed" are you
>>> >talking about the operating system code, or the architecture seen by
>>> >clients of the OS?
>>
>> Only talking about the OS itself not the clients.
>
> From your questions, it seems to me that you are assuming that all
>programs running under the OS (the clients of the OS) are managed and
>thus can safely share a single address space. Or am I misunderstanding?

Yes correct the OS and all applications are managed (type safe and garbage
collected) but also reference checked. At present the kernel only access
"user" address spaces to add received messages to the queue ( though
obviously we have some scheduling primitives to start/resume a user thread)
. 

>
>> Q2) How does the loader create the capability to a keyring ( nodepage
>or
>> capability page) for a new process
>
>I'm not sure where you got the term "keyring" or what it means to you.
>In EROS and CapROS a KeyRing is a structure that is used internally by
>the kernel for bookkeeping purposes, but is not exposed to the user.

It's my name for storage of a collection of capabilities. I think this is a
node page or a capability page in Coyotos / Eros. 

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

>
>> I note : In a capability system, a new program (we'll call it new) gets
>its
>> capabilities in two ways:
>>
>>    1.New receives an initial set of capabilities when it is created.
>These
>> are supplied by new's creator (which is another program).
>>    2.If another program receives a capability to new, it can invoke new
>and
>> pass it additional capabilities if it desires.
>> From. http://www.eros-os.org/essays/wherefrom.html
>>
>> But how is this handled in terms of storage of the capability and
>storage of
>> the pointer to the capability ? Or is there a special case that a
>process
>> can access the keyring without a capability.
>
>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.  Hence there are few storage issues with the
capability.

>> 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 or a practical reason due to language
implementation details? Just throwing up ideas at the moment. 

I noticed the invoke methods 

Now we have 
Syscall ( method id , param fields... , string by ref) 
Get capability for proc. 
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. 

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 ? 




Regards, 

Ben





More information about the cap-talk mailing list