1.3. Why a New OS?

The essential goal of the vortexOS project is to develop a robust, reliable, and secure general-purpose operating system. To achieve this, the following key design choices have been made:

Written in Rust

Whenever possible, vortexOS code is written in Rust. Rust enforces a strict set of rules and checks on the use, sharing, and deallocation of memory references. This almost entirely eliminates the potential for memory leaks, buffer overruns, use-after-free errors, and other memory-related issues that typically arise during development. The majority of security vulnerabilities in operating systems stem from memory errors, but the Rust compiler prevents these types of errors before they can be introduced into the codebase.

Microkernel Architecture

The Microkernel Architecture in vortexOS shifts as many components as possible out of the operating system kernel. Drivers, subsystems, and other operating system functionalities run as independent processes in user-space (daemons). The kernel's primary responsibility is to coordinate these processes and manage system resources.

Most kernels, except for some real-time operating systems, use an event-handler design. Hardware interrupts and application system calls each trigger an event that invokes the appropriate handler. The kernel operates in supervisor mode, with access to all system resources. In Monolithic Kernels, the entire operating system’s response to an event must be completed in supervisor mode. An error in the kernel, or even a malfunctioning piece of hardware, can cause the system to enter a state where it is unable to respond to any event. Due to the extensive amount of code in the kernel, the potential for vulnerabilities in supervisor mode is significantly higher compared to a microkernel design.

In vortexOS, drivers and many system services run in user mode, similar to user programs, and the system can restrict them so they only access the resources necessary for their designated purpose. If a driver fails or crashes, it can be ignored or restarted without impacting the rest of the system. A malfunctioning piece of hardware might affect system performance or cause the loss of a service, but the kernel will continue to function and provide whatever services remain available.

This makes vortexOS a unique opportunity to demonstrate the potential of microkernel architecture in mainstream operating systems.

Benefits

The following sections summarize the benefits of a microkernel design:

• True Modularity: You can modify or change many system components without needing to restart the system, offering a safer alternative to kernel modules and live patching.

• Bug Isolation: Most system components run in user-space on a microkernel system. As a result, bugs in most system components won't crash the entire system or kernel.

• Restartless Design: A mature microkernel undergoes very few changes (except for bug fixes), so you won’t need to restart your system often to update it. Since most system components are in user-space, they can be replaced on-the-fly, significantly reducing server downtime.

• Ease of Development and Debugging: Most system components run in user-space, simplifying testing and debugging.

You can read more about these benefits on this page.

Advanced Filesystem

vortexOS provides an advanced filesystem, nyxFS. It includes many features found in ZFS but offers a more modular design.

More details on nyxFS can be found here.

Unix-like Tools and API

vortexOS offers a Unix-like command interface, with many everyday tools written in Rust but with familiar names and options. Additionally, vortexOS system services include a programming interface that is a subset of the POSIX API, via relibc. This means that many Linux/POSIX programs can run on vortexOS with only recompilation. While the vortexOS team strongly prefers essential programs to be written in Rust, we are agnostic about the programming language for user-chosen programs. This provides an easy migration path for systems and programs previously developed for Unix-like platforms.