Managing Capabilities

OKL4 2.1 introduced a capability-based security model used to control access rights to certain kernel objects. This is achieved by restricting access to particular objects to users possessing the requisite tokens or capabilities. Each capability specifies the rights the user has with regards to the object, such as reading, modifying, or copying the capability.

OKL4 uses capabilities to manage access control to system resources. In the current version of the API, only thread objects are protected using capabilities. It is expected that the capability based security model will be extended to other objects in the future.

Capabilities can be used to construct secure systems in which communication between threads can be completely controlled using capabilities and capability spaces.

Capability Spaces

A capability space (cspace) is a collection of capabilities to which the user has access. The cspace may be shared with other threads, where all sharing parties have the same access rights to the objects represented by the capabilities.

In OKL4, each address space has a single associated capability space. All threads residing within the address space can access the capabilities contained in this cspace. A cspace may be shared by zero, one or many address spaces. cspaces are currently implemented as a capability list or clist object.

A clist is a first class kernel object and can be operated on using the CapControl system call.

At system startup, a root clist is created and associated with the root address space. The number of slots in the root clist are also configured at system startup. A cap to the initial root server thread is created in slot 0 of the root clist.

Further Reading

Capabilities are further described in libs/l4/include/caps.h, and Section A-4 Capabilities of the OKL4 Kernel Programming Manual. The CapControl system call is further described in Section A-11.2 of the OKL4 Kernel Programming Manual.