Processes

Apart from the kernel itself, all programs run in processes.

Why processes

Separating programs in threads presents several advantages:

  1. This allows to take advantage of multi-core architectures by running multiple programs in parallel
  2. Each program has its own data space and does not share its data with other programs
  3. Each process has its own permissions and thus cannot bypass what the user chosen

Types of processes

There are two types of processes:

This implies it is not possible to run an executable as standalone in its own process.

Process identifier

Each process is identified by a 64-bit number, which is guaranteed to be unique until the system restarts. When a process terminates, the PID is not freed. The PID is not randomly generated, but retrieved from a system-wide counter incremented when a new process starts. PID cannot be equal to 0.

System services can be identified by a PID strictly smaller than 100, while userland processes have a PID greater or equal to 100.

Process attributes

Each process has a set of attributes which contains critical informations on it (lists are usually PLL):

  • PID (8 bytes)
  • Priority (1 byte)
  • System marker (1 byte) to indicate if the process comes from a system program
  • Container's ID (8 bytes)
  • Running user's ID (8 bytes)
  • Parent application ANID (8 bytes) - 0 for system services
  • Pointer to the execution context (8 bytes) - 0 for system services
  • PLL(e=32) for memory mappings
  • PLL(e=32) for raw permissions
  • PLL(e=32) for drivable devices

Drivable devices

The drivable devices attribute contains the list of all devices' KDI the current process can drive.

The goal of this attribute is to determine if the process is allowed to map a device's memory by creating an AMS from it using the DEVICE_AMS syscall, as well as using DMA-related instructions in the CPU.

This attribute is managed by the sys::hw service and can only be updated by it.

Raw permissions

Raw permissions are used by system services to determine the permissions of a process without sending a message to the sys::perm service and waiting for its answer, which would be costly in terms of performance.

These permissions use a specific structure, specified in the related service's specifications document.

Permissions can be managed using the sys::perm service.