Reiterating again to simplify:
Working:
- Pager issues destroy, client also issues exit
they work in sync.
Missing
- Pager killing itself
- Pager killing all children while killing itself
- Pager waiting on children
One is related to the time distribution when a new child is created.
If the parent has one tick left, then both child and parent received
zero tick. When combined with
current_irq_nest_count = 1
voluntary_preempt = 0
values, this caused the scheduler from being invoked.
Second is related to the overall time distribution. When a thread
runs out of time, its new time slice is calculated by the below
formula:
new_timeslice = (thread_prio * SCHED_TICKS) / total_prio
If we consider total_prio is equal to the sum of the priorities of
all the threads in the system, it imposes a problem of getting
zero tick. In the new scenario, total_prio is equal to the priority
types in the system so it is fixed. Every thread gets a timeslice
in proportion of their priorities. Thus, there is no risk of taking
zero tick.
This malloc is a very simple first-fit sort of allocator. Now, it builds
without any problem but because we havent fixed include paths and added
it to the referenced libraries in the posix container yet, POSIX doesnt
build. So take it with caution.
(cherry picked from commit 65523743e86268eddd3bd2aab58476003f71c2c2)
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.
It is important to be able to create environments with not much
involvement with capability management. This is to increase usability
of the system and provide the option of having simpler api with
less security-oriented applications.
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.
Pagers can now share their own private capabilities with their
paged children, or their siblings with whom they have a common pager
ancestor.
Added flags CAP_SHARE_CHILD and CAP_SHARE_SIBLINGS for that.
Pagers by default do not share their capabilities with their children.
By using one of CAP_SHARE_SPACE, CAP_SHARE_GROUP or CAP_SHARE_CONTAINER
a pager may now share its capabilities with a collection of threads.
Test container is planned to test codezero microkernel extensively.
With these changes, everything is there to develop a full-featured test suite.
It also exemplifies how a new container type can be added to the system.
(cherry picked from commit f21fa53df421bfc8eeeaa096c89b98beed436c60)
Notion of pager hierarchy introduced using the existing but unused
pagerid field.
Thread creation now has two more flags TC_AS_PAGER and TC_SHARE_PAGER.
The former sets creator as pager, the latter sets creator's pager as pager.
Thread group capability sharing now correctly carries shared capabilities
to the thread group leader's tgr_cap_list list, and this list is checked
during capability checking.
Capabilities will be shared among collection of threads. A pager
will have a right to share its own capabilities with its space,
its thread group and its container.
Currently sharing is possible with only all of the caps. Next,
it will be support for cap splitting, granting, and partial sharing
and granting.
