OSDev.org

To avoid confusing anyone, I'll use standard terminology instead of Glider jargon.

It's the remix of this.

By now I have working processes and threads. I've implemented and tested my cross-address-space procedure-calling mechanism and can send you a paper about it by email (although I've already designed the next, better version). A single cross-address-space procedure call will be referred to as a portal call, borrowing words from Kea and Pebble.

Now I have to confront the issues of security and naming. Basically, the kernel only knows about one type of inter-process communication: the interface. An interface is just a list of publicly available procedure calls to which anyone with the correct authority can obtain portals. Interfaces have a fixed set of operations on them defined by a set of system-call portals.

Note that these interfaces are not bound to any kind of inputs. The function calls are not curried or object-oriented.

This becomes trouble when dealing with normal, everyday server processes. A fileserver needs to protect files somehow; it also needs to denote and name them. The former is normally accomplished with filesystem permissions, the latter with filenames and open-file descriptors.

My design puts authority and naming in capabilities. Every process and thread has its own C-list. Processes and threads can only access things outside themselves via their capabilities.

I noticed some neat properties when I thought about the use of capabilities.

Rather than pass a rights bitmap around in capabilities that decides what operations a user can make a given portal-call of a given interface, a list of allowed operations can be stored in the capability itself. A system call would allow anyone with the right capability to create a new interface object from a subset of one they can already access. This would work no matter how many operations the interface contained. The only drawback is that capabilities become kernel-space objects instead of cryptographically protected user-space structures.

As long object-orientation isn't used in the interface in question and a program needs a capability with a certain right to obtain a portal to a given operation, just having that portal constitutes prima facie evidence of the right to perform that operation.

This allows the creation of a concentric-ring structure of interfaces, where programs with greater authority receive large interfaces, break off small chunks, and pass those chunks to less trusted programs. The less-trusted programs may never even know the larger interface exists, enhancing the security of the system even in the case that someone successfully forged authority to perform an operation.

For lack of another term in the capability papers I've read, I call this the Subset Delegation Property. Oops, coined a term. Have to learn to stop that.

All this changes when you start talking about objects. All of a sudden you can have two capabilities to two separate files that use the exact same interface. In addition, most objects (like files, network connections, GUI windows, etc.) are not implemented in the kernel. It may have some information about their interfaces, but it doesn't hold them in memory.

However, some (like virtual memory regions, processes, threads, and interfaces) are implemented in the kernel.

The first question is: Is it worthwhile to create a capability system that denotes anything more than interfaces? Why?
The second question: Is it worthwhile to create a universal capability system that can denote all objects on the system? How? Why?

Note that the "how" is rather complicated. What is an object? Usually, it's instance data and an interface. The interface, of course, will be in-kernel whether or not the capability system can denote the whole object. Instance data should stay outside the kernel, where it's useful.

So let's say that servers make objects visible to the kernel as references to interfaces with a set of rights referring to operations in the interface instead of operations on the interface. Client programs receive capabilities to these kernel-visible objects and use them to pbtain portals for the objects' interfaces. Clients then pass these capabilities to operations on the objects to denote particular rights to particular objects.

Now the server's received a capability to one of its own objects. The third question is: How can the server extract an identifier or location of an object's instance data from a capability to that object?

Assuming kernel-space capabilities, you have to wonder how a capability gets passed from a client process to a server process for use. Simple: the client program puts it on its thread's C-list before calling the server. Threads migrate on portal calls, so the thread C-list doesn't change between processes.

Finally, note that since many objects can use the same interface, interfaces of objects do not have the Subset Delegation Property. Creating a File Object without Write() in its rights-list will not stop an attacker from calling Write() on that File Object. The server must actually verify the rights of the capability passed to it before going ahead and operating on the File Object that capability denotes. Thus, the fourth question is: Is it worthwhile to implement rights lists (and therefore make capabilities kernel-space objects), or will plain, old rights bitmaps suffice (letting capabilities be user-space structures)?

I hope I've managed to interest somebody for at least 5 minutes.