MOSA-0003: MOSA Kernel and Process Model
This RFC discusses the MOSA process model in an architecture independent way. The kernel model provides foundations to run kernel services, drivers and applications in processes in various isolation levels. This RFC specifies various parts with respect to this
goal. This RFC also defines the way kernel services offer their features to other processes, how applications can take advantage of these services and the way hardware is integrated into this model. The architecture defined in this RFC also provides foundations
in order to secure and isolate applications from the system and from each other. It provides a means to run individual applications or services in a sandbox in full isolation from the remainder of the system.
The following table defines some terms used in this RFC. These definitions are specific to this RFC and may differ in their meaning from other uses.
A process is a collection of operating system resources, an address space and a Program to execute. A process assumes exclusive use of these resources. A process contains at least one AppDomain. Note that processes can share address spaces or receive their
own private address space.
AppDomains are a core concept of .NET available since the very first version. .NET coined the term lightweight process to indicate that AppDomains have features of a process, but run together in a single operating system process. The AppDomains are protected
from each other by the CLR, there's no operating system protection between AppDomains.
A driver is a binary file, which is able to perform certain tasks on a specific piece of hardware.
A Program is a piece of executable code, which has an entry point (the main function) available to the CLR. When a program is executed a new process is created and the executable is loaded into this process for execution.
A service is a programm or component, which realizes a standard interface and runs in the context of a Process/AppDomain. Its interface is available to other component or programs to use.
A sandbox isolates a program from the remainder of the system in order to prevent potentially malicious changes outside of the scope of the programm itself.
The MOSA kernel model is best summarized by the
model. It shares a lot of design choices with the Mach kernel or the Windows NT kernel, however the actual layout of the kernel, its functions, modules and services is determined dynamically during kernel initialization.
An operating system kernel provides a set of functions (grouped into modules) to running applications:
- Virtual Memory Management
- Power Management
- IPC services
- I/O services
The MOSA Project is no different from a classical operating system in offering these functions. However there are a lot of differences: The first difference is that kernel functions are not exposed by static methods on one or more kernel classes. The functions
are grouped into interfaces, which are exposed by kernel services, as illustrated in the following image:
A class implements the interface in order to realize the functionality described by it and exposes the functionality for others to use. This approach is used by services, drivers and applications in order to allow interoperability. All of these expose interfaces
in order to be callable by others.
The object manager is the central component of a MOSA kernel and provides a hierarchical namespace. Instead of naming arbitrary streams, the object manager contains globally published object references of services to expose to other components. The ObjectManager
keeps objects alive until they're no longer used by a service or are explicitly deleted from its namespace. The object manager also performs appropriate security checks and change notifications if parts of the tree are changed while the system is running.
This allows apps to monitor the availability of files, devices, network connections, running services etc.
This namespace is extensible by each node in the tree: Any node in the tree can act as a container and provide additional child nodes like a directory in the file system. The ObjectManager keeps track only of the nodes references by another services or recently
File systems are also integrated in the ObjectManager namespace, which makes the ObjectManager an equivalent of a virtual file system. Allowing transparent retrievel of appropriate interfaces for files, folders and streams located on a file system.
The services exposed by a MOSA kernel are location transparent, as there's only an interface required to use them. The implementation of the interface can run in the kernel process, in a specific process or a shared service process. .NET remoting is used
to properly hide the required context switches between processes (if required.)
The model does not define the location of these services, it is up to the kernel initialization to determine the actual execution location of the various services it will provide. However the typical kernel process will only contain a little number of services
itself, which can be summarized by the following points:
- Object manager
- Physical Memory Management
- Boot control & boot file system drivers
- Power Management
All code executed in a MOSA operating system runs in a process. All processes have the following properties:
- A process has a single instance of the MOSA VM (CLR)
- A process has a System AppDomain
- A process has one or more AppDomains, which execute (user) code
- A process has its own jit, has an address space, a virtual memory manager and access to MOSA kernel services
- A process may run inside a sandbox
- A process may run child processes
Processes are registered in the ObjectManager. The architecture of MOSA processes allows them to use a specific version of the MOSA Runtime equivalent to their .NET version. A mapping of the types used by the kernel and the process itself is provided by the
remoting channel used to communicate accross process boundaries.
Processes are started by a process launcher service registered in the ObjectManager. The initial code executed in a process initializes the local VM and connects to the ObjectManager passed to the process. This allows for various security and sandboxing techniques,
as the parent process is responsible for passing an ObjectManager to the child process. The passed ObjectManager may be the kernel object manager or one specially build for the launched process.
The following diagramm depicts a process hierarchy as it may run on a MOSA based operating system. The following sections will describe features based on this diagram.
The boxes with rounded corners depict a process with their own address space. The rectangular boxes depict AppDomains running in the process. In the hierarchy, there 5 processes with a total of 8 running AppDomains.
Processes maintain a hierarchy as they are launched. A parent process is always alive as long as at least one of its children is running and or if it is executing code itself. This is done in order to facilitate the Sandboxes described below. If all AppDomains
in a Process terminate before the children, the System AppDomain is kept alive until all children have terminated. If the last (non-System) AppDomain in the parent crashes, the entire process tree dies. This basically groups processes, which can be terminated
together by terminating the appropriate common ancestor.
In the diagramm above, terminating the ServiceManager process will terminate the PrintServer and VolumeServer processes too.
The process model associates the real cost of the resources used by a process with the process itself. In most operating systems the cost of resources occupied in driver processes or the kernel itself is not accounted for in the process, which originally requested
the resource. This causes unexplainable memory usage in most cases, where it is not traceable which process is responsible for specific requests. Through the use of proxies (in order to remote the calls) retrieved from the object manager all costs (memory,
cpu time, ...) are accounted for in the process requesting them. This allows exact accounting of these uses and appropriate action or reaction by the scheduler or the administrator of the device. The accounting is performed by installing appropriate interceptors
in the ObjectManager.
Since there are various levels of trust employed to programs coming from different sources, the .NET model is sufficient for a lot of cases. However MOSA adds an additional layer of security on top of the existing facilities by allowing one to create processes
running in a sandbox. A sandbox is essentially a special ObjectManager, which hides the kernel object manager and only passes those services on, which are enabled for the process. This Sandbox ObjectManager hides all unsafe or unwanted services from the child
process, presents a different root directory to the file systems (in order to constrain the app to specific folders) and monitors the requests for kernel services.
Sandboxing does not necessarily prevent access to all services, but can ask the user for appropriate consent before performing actions on requested interfaces. It also allows the installation of transparent proxies, which log, check access rights or modify
calls made to real services.
From this document a number of requirements are made to the boot process. The following points summarize in short the tasks required to boot a MOSA based operating system. These points are not complete however, as this largely depends on the target hardware
- Configure memory management (Change memory model)
- Optional: Move the kernel in memory
- Reserve physical memory for the kernel
- Create a stack for the initial thread
- Create a stack for the interrupt handler thread
- Install the main interrupt handler to dispatch interrupts
- Enable interrupts
- Enable additional CPUs
- Create the root ObjectManager
- Create the system process manager
- Create a system process for the kernel itself
- Start the device manager
- Add fixed system devices (timers, ports, ...)
- Start the system scheduler
- Subscribe, configure a timer resource
- Setup a main thread for the system process
- Start the hardware detection & servicing process(es)
- Start the service manager to run background services
- Launches optional services
- Start the session manager to maintain user sessions
- Initialize the system session
- Attach to all graphics adapters available (Listen for new ones to arrive)
- Start the desktop rendering process
- Launch the logon shell in a logon session