Normally a pointer with its topmost bits set may cause false errors
due to the fact that such pointers result in negative integer casts.
The remedy is to use IS_ERR() macro that accepts only down to -1000
as error and any values below as valid.
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.
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.
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.
Modifying task_virt_to_page() so that it takes into account page
protections. If mm0 writes to a task page that is meant to be
read-only, (e.g. the zero page) the design is broken.
Every access to a task's page will take the page fault route,
and the page fault handler will return the page instead of 0.
bss segment may have some of it at the end of data, but the bits
that lie on a new page need to be mmaped as anonymous. When this
occured we were not passing the new page boundary but the last
data page where bss started
Currently, the tid returned from kernel contains container id as
well, which makes it sufficient to do inter-container syscalls without
any preparation.
The helpers added are for presentation purposes only. Container id
is deleted so that the raw thread id is available for printing or
similar.
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.
