It is not very straightforward to reach a capabilities list. We
now use a single function to find out a capability by its id and
its list, since the two are used frequently together (i.e. cap
removal and destruction)
Implemented a protocol between a client and its pager to
request and get a capability to ipc to another client of the pager.
Pager first ensures the request is valid from its client.
It then tries to use a greater capability that it possesses, to
produce a new capability that the client requested. Once the kernel
validates the correct one and replicates/reduces it to client's
need, it grants it to the client.
Pager handles client capability requests by using one of its own
capabilities to create a new one that suits the client's needs.
The current issue is that the kernel can have multiple caps and it
may not know which one is suitable for using to create one for the client.
The kernel knows this very well, so the solution would be to attempt to
use capabilities that roughly match (i.e. by type) and leave it to
the kernel to decide whether it is any powerful to suit client's needs.
We moved initial list of a pager's caps from ktcb to task's space
since the task is expected to trust its space.
Most references to task->cap_list had to change. Although a single
cap list only tells part of the story about the task's caps, the
TASK_CAP_LIST macro works for us to get the first private set of
caps that a task has.
Capability checking for thread_control, exregs, mutex, cap_control,
ipc, and map system calls.
The visualised model is implemented in code that compiles, but
actual functionality hasn't been tested.
Need to add:
- Dynamic assignment of initial resources matching with what's
defined in the configuration.
- A paged-thread-group, since that would be a logical group of
seperation from a capability point-of-view.
- Resource ids for various tasks. E.g.
- Memory capabilities don't have target resources.
- Thread capability assumes current container for THREAD_CREATE.
- Mutex syscall assumes current thread (this one may not need
any changing)
- cap_control syscall assumes current thread. It may happen to
be that another thread's capability list is manipulated.
Last but not least:
- A simple and easy-to-use userspace library for dynamic expansion
of resource domains as new resources are created such as threads.
