All pages
Powered by GitBook
1 of 9

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

1. Introducing Nyxos

Nyxos is a microkernel-based operating system, featuring a wide array of supported programs and components designed to create a comprehensive user and application environment. In this chapter, we will explore the goals, philosophy, and scope of Nyxos.

1.3. Why a New OS?

The essential goal of the Nyxos 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, Nyxos 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 Nyxos 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 Nyxos, 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 Nyxos 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.

You can read more about these benefits on this page.

Advanced Filesystem

Nyxos 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

Nyxos offers a Unix-like command interface, with many everyday tools written in Rust but with familiar names and options. Additionally, Nyxos 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 Nyxos with only recompilation. While the Nyxos 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.

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

1.6. Why Rust?

Why We Chose to Write an Operating System in Rust

Rust offers significant advantages, especially in the context of operating systems, where security and stability are paramount. Operating systems are foundational to computing, making them the most crucial piece of software. Throughout the history of computing, there have been numerous bugs and vulnerabilities in systems like Linux, BSD, glibc, Bash, and X11, often stemming from issues related to memory allocation and type safety. Rust addresses these issues by enforcing memory safety at the compile-time, which is crucial for preventing such vulnerabilities.

The Importance of Rust in OS Development

Design is important, but so is the implementation. Rust excels in preventing unexpected memory-unsafe conditions, which are a major source of security-critical bugs. Rust's design is transparent, allowing developers to clearly understand what is happening in the code and what the intended behavior is.

The basic design of the kernel and user-space separation in Nyxos is similar to Unix-like systems. The core idea is to separate the kernel and user-space, with the kernel strictly enforcing system resource management. However, Nyxos has a significant advantage: enforced memory and type safety. Rust's strength lies in eliminating a large number of "unexpected bugs," such as undefined behavior, at compile-time.

While the design of Linux and BSD is secure, their implementation is not. Many bugs in Linux stem from unsafe conditions—like buffer overflows—that Rust effectively eliminates. By using Rust, we aim to produce a more secure and stable operating system.

The Role of unsafe in Rust

unsafe is a mechanism in Rust that allows developers to perform operations that the compiler cannot guarantee to be safe, such as low-level memory manipulation. While you cannot write a kernel without using unsafe, Rust requires that these unsafe operations be explicitly marked as such. This keeps the unsafe parts isolated from the rest of the safe code. We aim to minimize the use of unsafe where possible, and when we do use it, we do so with extreme caution.

This approach contrasts with kernels written in C, where no guarantees about security can be made without costly formal analysis. In Rust, the use of unsafe is carefully controlled, enhancing overall system safety.

Benefits of Writing Nyxos in Rust

1. Reduced Likelihood of Bugs

The restrictive syntax and strict compiler requirements of Rust significantly reduce the probability of bugs in the code.

2. Less Vulnerability to Data Corruption

The Rust compiler helps programmers avoid memory errors and race conditions, reducing the chances of data corruption bugs.

3. No Need for C/C++ Exploit Mitigations

The microkernel design, when written in Rust, is naturally protected against the memory defects commonly seen in software written in C/C++. By isolating system components from the kernel, the attack surface is significantly reduced.

4. Improved Security and Reliability Without Performance Impact

The small size of the kernel means it uses less memory, helping to maintain a bug-free status (KISS principle). Rust’s combination of safe and fast language design, along with the minimal kernel code size, ensures a reliable, performant, and easy-to-maintain core.

5. Thread-Safety

C/C++ support for thread safety is fragile, making it easy to introduce subtle bugs or security holes when running programs across multiple threads. Rust's type system prevents the writing of unsafe concurrent access patterns, helping to avoid these issues. This ensures that Nyxos is less prone to bugs related to thread safety.

6. Rust-Written Drivers

Drivers written in Rust are likely to have fewer bugs, making them more stable and secure, contributing to the overall reliability of Nyxos.

By choosing Rust for Nyxos, we are working towards creating an operating system that is not only secure and stable but also efficient and reliable, setting a new standard for operating system development.

1.2. Our Philosophy

Nyxos is primarily licensed under the MIT X11-style license, which covers all software, documentation, and fonts within the project. There are only a few exceptions to this, all of which are licensed under other compatible open-source licenses.

The MIT X11-style license offers the following benefits:

  • Unrestricted Access: It grants you, the user, full and unrestricted access to the software, allowing you to inspect, modify, and redistribute your changes.

  • Inspection: Anyone is permitted to inspect the software to identify any security vulnerabilities.

  • Modification: Anyone can modify the software to address security vulnerabilities.

  • Redistribution: Anyone can redistribute the software to patch any discovered security vulnerabilities.

  • GPL Compatibility: It is compatible with GPL licenses, meaning that projects licensed under GPL can be distributed with Nyxos.

  • Incorporation of GPL-Incompatible Free Software: The license permits the inclusion of GPL-incompatible free software, such as OpenZFS, which is licensed under CDDL.

Moreover, the license does not impose restrictions on the software that can run on Nyxos. Thanks to the microkernel architecture, even components that are traditionally tightly coupled, like drivers, can be distributed separately, allowing maintainers to choose any license they prefer for their projects.

Nyxosis committed to being free forever, as we aspire to be a foundational element in the creation of secure and resilient systems.

1.1 Our Goals

nyxOS is an effort to create a complete, fully functional, general-purpose operating system with a strong emphasis on safety, freedom, stability, correctness, and practicality. Our goal is to use it without barriers as a full-fledged alternative to Linux/BSD on our computers. It should be capable of running most Linux/BSD programs with minimal modifications.

We are striving to build a complete, stable, and secure Rust ecosystem. This is a deliberate design choice intended to enhance correctness and security (see Why Rust). Our aim is to improve security design compared to other Unix-like operating systems by adopting safe defaults and minimizing insecure configurations wherever possible.

The Non-Goals of nyxOS

We are not trying to be a Linux/BSD clone or POSIX-compliant, nor are we attempting to radically redesign everything. Generally, we adhere to well-tested and proven designs. If it isn’t broken, don’t fix it.

This approach ensures that a significant number of programs and libraries will be compatible with nyxOS. However, some elements that do not align with our design choices may need to be ported. The key here is balancing correctness with compatibility. Ideally, both should be achievable, but unfortunately, this is not always possible.

1.4. Nyxos Use Cases

Nyxos is a general-purpose operating system that can be utilized in a variety of scenarios. Some of the key use cases for Nyxos are as follows:

Server

Nyxos has the potential to be a secure server platform for cloud services and web hosting. The enhanced safety and reliability that Nyxos aims to provide as it matures make it an excellent fit for the server environment. There is ongoing work to support crucial server technologies such as databases and web servers, as well as compatibility with high-end server hardware.

Plans are also underway for virtualization support in Nyxos. Although running an instance of Linux in a container on Nyxos may forfeit some of the unique benefits of Nyxos, it can still help to limit the scope of vulnerabilities. Virtualization of Nyxos-on-Nyxos and Linux-on-Nyxos has the potential to be much more secure than Linux-on-Linux. These capabilities are still in development but are among the goals of the Nyxos team.

Desktop

The development of Nyxos for the desktop is well underway. Although support for accelerated graphics is currently limited, Nyxos does include a graphical user interface and support for Rust-written GUI libraries like winit, Iced, and Slint.

A demo version of Nyxos is available with several games and programs to explore. However, the primary objective for the desktop environment is to host the development of Nyxos itself. We are addressing issues with some of our build tools, and other developer tools such as editors have not yet been fully tested for daily use, but we continue to prioritize this.

Due to a relatively limited list of currently supported hardware, once self-hosted development becomes available, development can be performed within Nyxos for quicker testing. We are continuously expanding hardware compatibility, and we aim to support development on a wide range of desktops and notebooks in the near future.

Infrastructure

Nyxos's modular architecture makes it an ideal candidate for various telecom infrastructure applications, such as routers, telecom components, edge servers, and more, especially as additional functionality is integrated into these devices. While there are no specific plans for remote management yet, Nyxos's potential for security and reliability makes it well-suited for this type of application.

Embedded and IoT

For embedded systems with complex user interfaces and extensive feature sets, Nyxos has the potential to be an excellent fit. As everyday appliances become internet-connected devices with sensors, microphones, and cameras, they become vulnerable to attacks that could infringe upon consumer privacy within their homes. Nyxos can offer a full-featured, reliable operating system while minimizing the likelihood of such attacks. Currently, Nyxos does not yet support touchscreens, video capture, or sensors and buttons, but these are well-understood technologies that can be added as they become a priority.

Mission-Critical Applications

Although there are no immediate plans to develop a version of Nyxos for mission-critical applications such as satellites or air safety systems, this possibility is not entirely out of reach. As tools for correctness proofs of Rust software continue to improve, it may eventually be possible to create a version of Nyxos that is proven correct within practical limits.

1.7. Influences

How Nyxos Was Influenced by Other Operating Systems

Plan 9

Plan 9, an operating system developed by Bell Labs, brings the concept of "Everything is a File" to its highest level by handling all system communication through the filesystem. This philosophy has strongly influenced Nyxos, which adopts a similar approach to create a more unified and efficient system API.

Minix

Minix is one of the most influential Unix-like systems with a microkernel architecture. It includes advanced features such as system modularity, kernel panic resistance, driver reincarnation, protection against faulty drivers, and secure interfaces for process communication. Nyxos is heavily influenced by Minix, sharing a similar architecture but with a feature set implemented in Rust, which enhances both security and reliability.

seL4

seL4 is known as the most performant and simplest microkernel in the world. Nyxos follows similar principles, striving to keep the kernel space as minimal as possible by moving components to user space and reducing the number of system calls. This approach not only simplifies the kernel but also maintains overall system performance by minimizing the cost of context switching.

BSD

The BSD family of Unix systems introduced several improvements to the original Unix systems, and the open-source variants of BSD brought many additional enhancements. Specific influences on Nyxos include:

  • FreeBSD: The Capsicum (a capability-based security system) and jails (a sandbox technology) from FreeBSD have influenced the implementation of namespaces in Nyxos.

  • OpenBSD: The system call, filesystem, display server, and audio server sandboxes from OpenBSD have inspired various security features in Nyxos.

Linux

Linux, the most advanced monolithic kernel and the largest open-source project in the world, has introduced numerous improvements and optimizations to Unix-like systems. Nyxos aims to implement these performance enhancements within a microkernel design, combining the efficiency of Linux with the security and modularity of a microkernel architecture.

1.8. Hardware Support

There are billions of devices across hundreds of models and architectures globally. We aim to develop drivers for the most commonly used devices to reach a wider audience. Support is dependent on the specific hardware, as some drivers are tailored to specific devices while others are architecture-specific.

You can check HARDWARE.md for a list of all tested computers.

CPU

  • Intel: 64-bit (x86_64) and 32-bit (i686) from Pentium II onwards with certain limitations.

  • AMD: 64-bit (AMD64) and 32-bit.

1.5. Comparing Nyxos to Other OSes

We share quite a lot with other operating systems.

System Calls

The Nyxos API is Unix-like. For instance, we have system calls like open, pipe, pipe2, lseek, read, write, brk, execv, and so on. Currently, we support the most common POSIX and Linux system calls.

However, Nyxos does not necessarily implement them as direct system calls. Much of the functionality for these operations (typically the man(2) functions) is provided in user space through an interface library, relibc.

ARM: 64-bit (Aarch64) with some limitations.

Why aren't CPUs older than i686 supported?

i686 (essentially Pentium II) introduced a variety of features that are crucial for the Nyxos kernel. While it's technically possible to support older CPUs like the i486, doing so would mean losing valuable functions such as fxsave/fxrstor, and we would need to build the userspace without any SSE code. Additionally, i386 lacks atomic operations entirely, making it an unlikely target.

Hardware Interfaces

  • ACPI

  • PCI

  • (USB support coming soon)

Video

  • VGA - (BIOS)

  • GOP (UEFI)

  • LLVMpipe (OpenGL CPU emulation)

  • (Support for Intel/AMD and others in the future)

Sound

  • Intel chipsets

  • Realtek chipsets

  • PC speaker

  • (Sound Blaster support coming soon)

Storage

  • IDE (PATA)

  • SATA (AHCI)

  • NVMe

  • (USB support coming soon)

Input

  • PS/2 keyboards, mice, and touchpads

  • USB keyboards, mice, and touchpads

Internet

  • Intel Gigabit Ethernet

  • Intel 10 Gigabit Ethernet

  • Realtek Ethernet

  • (Support for Wi-Fi and Atheros Ethernet coming soon)

I have a low-end computer, would Nyxos work on it?

A CPU is one of the most complex machines in the world; even the oldest processors are capable of handling some tasks but may struggle with others. The primary challenge with older computers is the limited amount of RAM available (as they were sold during a time when RAM was expensive) and the lack of SSE/AVX extensions (which modern programs use to accelerate algorithms). As a result, some contemporary software may not function properly or may require substantial amounts of RAM to handle complex tasks.

nyxOS itself will generally operate if the processor architecture is supported by the system, but the performance and stability can vary depending on the program.

"Everything is a File"

In a model largely inspired by Plan 9, in Nyxos, resources can be socket-like or file-like, providing a more unified system API. Resources are named using paths, similar to what you would find in Linux or another Unix system. However, when referring to a resource managed by a particular resource manager, you can address it using a scheme-rooted path. We will explain this later in Schemes and Resources.

The Kernel

Nyxos's kernel is a microkernel, with an architecture largely inspired by MINIX and seL4.

In contrast to Linux or BSD, Nyxos has around 50,000 lines of kernel code, a number that is often decreasing. Most system services are provided in user space, either through an interface library or as daemons.

Having a vastly smaller amount of code in the kernel makes it easier to efficiently identify and fix bugs and security issues. Andrew Tanenbaum (author of MINIX) stated that for every 1,000 lines of properly written C code, there is a bug. This implies that in a monolithic kernel with nearly 25,000,000 lines of C code, there could be nearly 25,000 bugs. A microkernel with only 50,000 lines of C code would likely contain around 50 bugs.

It's important to note that the extra code is not discarded; it is simply based outside of kernel space, making it less hazardous.

The primary idea is to ensure that system components and drivers, which would typically reside within a monolithic kernel, exist in user space and adhere to the Principle of Least Authority (POLA). This means that each component is:

  • Completely isolated in memory as separate user processes (daemons).

  • The failure of one component does not crash other components.

  • Foreign and untrusted code does not compromise the entire system.

  • Bugs and malware cannot spread to other components.

  • Communication with other components is restricted.

  • Lacks Admin/Super-User privileges.

  • Bugs are confined to user space, reducing their potential impact.

All of these factors significantly enhance the system's reliability, which is crucial for users seeking minimal issues with their computers or for mission-critical applications.