l4_capability_control works well for almost all system calls
using a buffer pointer to the capability that it operates on.
Only for sharing/granting of capability lists, it is yet to be
decided how to provide a grant target id.
Added 8 notify slots of 1 byte each. These will be notification
slots for irqs and other threads.
Also now userspace refers to kernel's utcb definition, so they're
in sync.
A 16-bit device number or id further distinguishes a device on the
system in addition to the device type. This is meant to be used for
the very first identification of the device for further probing. Any
further info is available by userspace mapping and probing.
Followed the kernel physical memory reservation convention
with devices. Devices that are possessable by userspace
are created as boot-time capabilities and placed under the kernel
resources devmem_free capability list. Any userspace container
that is defined with the possession of the device would delete the
device capability making it unavailable to further requests.
cinfo array is now freed along with other init memory.
bootmem allocator memory is reduced to be completely used up.
free boot memory now prints the used free memory as well.
Each container was taking up more than 3KB of space at boot-time structures
This was due to having 4 pagers and 32 boot-time capabilities for each. This
caused the boot-time kernel size to vary a lot with capabilities. The new
numbers are optimum.
Particularly we always have a single pager per container, even though the
array structures allow more. Single pager makes container-wide privileges
and management simpler.
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.
In posix, test0 makes inter-space ipc for testing extended ipc. This
correctly fails when only the cap to ipc to pager is given to all tasks
in the container.
In order to overcome this problem, the tasks who fork for doing ipc to
each other make a request to the pager to get capabilities to do so.
Pager finds its own widened ipc capability over the container, replicates
it, validates and reduces it to desired boundaries (i.e. just ipc betw.
two spaces) and grants it as IMMUTABLE to requesting tasks.
This protocol may be useful in implementing a client/server capability
request relationship. Code builds but untested.
Thread ids now contain their container ids in the top 2 nibbles.
Threads on other containers can be addressed by changing those
two nibbles. The addressing of inter-container threads are
subject to capabilities.
Task ids are now unsigned as the container ids will need to be encoded
in the id fields as well.
For requests who require even more comprehensive id input, (such as
thread creation) also added is the container id so that threads
_could_ potentially be created in other containers as well.
VIRTMEM and PHYSMEM are theoretically separate resources to be
protected than a MAP resource, which is meant to protect the syscall
privileges.
In practice MAP is always used together with a VIRTMEM and a PHYSMEM
resource, therefore reach VIRTMEM/PHYSMEM resource is now merged with
the MAP capability, combining the micro-permission bits.
We still have to have the pager structs because they possess intermediate
data during boot up such as for transferring of capability lists to
boot stack one-by-one, and then to newly generated ktcbs.
