MOSA-0003: MOSA Kernel and Process Model

Status Draft
Discussions MOSA-0003: MOSA Kernel and Process Model (Discussion)



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.

Kernel Model

The MOSA kernel model is best summarized by the hybrid kernel 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.

Kernel Functions

An operating system kernel provides a set of functions (grouped into modules) to running applications:
  • Virtual Memory Management
  • Power Management
  • IPC services
  • Security
  • 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.

Object Manager

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 accessed.

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.

Location Transparency

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
  • HAL
  • Physical Memory Management
  • Boot control & boot file system drivers
  • Power Management
  • Scheduler

Process Model

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.

Process startup

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.

Process Hierarchy

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.

Process Lifetime

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.

Resource Management

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 architecture.
  • 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)
      • Enable interrupts
    • 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

Last edited Jan 8, 2009 at 12:31 AM by __grover, version 12


No comments yet.