MysticOS’ kernel uses an exokernel based design, which ultimately means that all choices should be up to the programmer. This allows the greatest amount of freedom to the programmer, but also makes him face the burden of having to deal with the details. For that reason, the kernel should be accompanied by a set of libraries which abstract the primitives of the hardware to more manageable levels.
The kernel is the component that has the ultimate control over hardware. This is the first layer of security. The kernel’s single goal is to stay operational independent of the rest of the system, while exposing as much control to anything else the system is shared with - devices, drivers, services and applications. Since the kernel uses memory and processor time, these are the key features it needs to protect where possible. The kernel also controls interrupt management, since in all CPU designs such an event changes the privileges to levels unacceptable for regular execution. To control processor time, the kernel controls a number of clock devices. Access to other devices is granted to other running modules.
To support the safety and separation of user modules, not all control available is allowed to each module. Instead privileges are handed out to the first module requesting them, which can then decide to share these privileges with other modules.
Note that some systems do not allow for guaranteed safety without crippling features. The key reasons for this are uncontrolled DMA and the absence of an MMU. These break the safety of kernel memory, but can not normally be restricted without severe sacrifices in performance.
To improve security on a higher level, the kernel will support four levels of security: host, driver, protected, unprivileged. The host level has access to all controls, including the ones that can affect unrelated applications. Drivers have most controls but do not normally affect unrelated applications, other than by means of external hardware the kernel is unaware of (DMA access). All other levels are guaranteed safe, where the protected level has the ability to acquire capabilities, and the unprivileged level does not.
Physical memory is managed as a capability where the module is able to access it. That means a program acquires the capability by mapping a segment of virtual memory to the requested physical memory. This capability can be transferred by mapping the memory in other address spaces. The kernel furthermore allows the creation of address spaces in various forms to expose the functionality of the MMU. An address space can be legacy paged, PAE-paged, long mode paged or segmented. Segmentation can be used in paged modes as well, in which case a thread is associated with parts of the virtual address space. This allows the user to implement multiple smaller address spaces within a single TLB. The kernel keeps track of used memory by counting references.