Redox OS 0.7.0 released: A Rust Operating System
Redox is an operating system written in Rust, a language with a focus on safety and high performance. Redox, following the microkernel design, aims to be secure, usable, and free. Redox is inspired by previous kernels and operating systems, such as SeL4, MINIX, Plan 9, and BSD.
Redox is not just a kernel, it’s a full-featured Operating System, providing packages (memory allocator, file system, display manager, core utilities, etc.) that together make up a functional and convenient operating system. You can loosely think of it as the GNU or BSD ecosystem, but in a memory safe language and with modern technology.
How Redox compares to other operating systems
Syscalls
The syscall interface is very Unix-y. For example, we have open, pipe, pipe2, lseek, read, write, brk, execv, and so on. Currently, we support the 31 most common Linux syscalls.
Compared to Linux, our syscall interface is much more minimal. This is not because of the stage in development, but because of a minimalist design.
“Everything is a URL”
This is a generalization of “Everything is a file”, largely inspired by Plan 9. In Redox, “resources” (will be explained later) can be both socket-like and file-like, making them fast enough for using them for virtually everything.
This way we get a more unified system API. We will explain this later, in URLs, schemes, and resources.
The kernel
Redox’s kernel is a microkernel. The architecture is largely inspired by MINIX.
In contrast to Linux or BSD, Redox has only 16,000 lines of kernel code, a number that is often decreasing. Most services are provided in user space
Having vastly smaller amounts of code in the kernel makes it easier to find and fix bugs/security issues more efficiently. Andrew Tanenbaum (author of MINIX) stated that for every 1,000 lines of properly written code, there is a bug. This means that for a monolithic kernel which could average over 15,000,000 lines of code, there could be at least 15,000 bugs. A microkernel which usually averages 15,000 lines of code would mean that at least 15 bugs exist.
It should be noted that the extra lines are simply based outside of kernel space, making them less dangerous, not necessarily a smaller number.
The main idea is to have components and drivers that would be inside a monolithic kernel exist in user space and follow the Principle of Least Authority (POLA). This is where every individual component is:
- Completely isolated in memory and as separate user processes
- The failure of one component does not crash other components
- Allows foreign and untrusted code to not expose the entire system
- Bugs and malware cannot spread to other components
- Has restricted communication with other components
- Doesn’t have Admin/Super-User privileges
- Bugs are moved to userspace which reduces their power
All of this increases the reliability of the system significantly. This would be useful for mission-critical applications and for users that want minimal issues with their computer systems.
Changelog v0.7
- bootloader: The bootloader was completely rewritten so that both the BIOS and UEFI versions share most of the same code, and are both predominantly written in Rust. This has led to greatly improved hardware support, and allowed for RedoxFS to be improved.
- kernel: A number of fixes and new features were added to the kernel, and code was removed. Hardware support was improved, as well as performance.
- Preliminary support for aarch64 has been added
- All paths are now required to be UTF-8, and the kernel enforces this
- CPU specific variables use the GS register, with various improvements coming from this
- All physical memory is mapped, recursive paging has been removed
- ACPI AML code was moved to acpid, a new userspace daemon
- Inline assembly rewritten to be stable with future compilers
- Initfs moved to a new file, which significantly improves packaging
- Many kernel issues have been fixed
- redoxfs: RedoxFS was rewritten to be a Copy-on-Write filesystem, with transactional updates and signatures for both metadata and data. This design greatly increases the reliability of RedoxFS. Additionally, transparent encryption was added, using AES with hardware acceleration if available. The bootloader now uses the same driver code as the operating system does, and this allows the bootloader to unlock the filesystem, allowing the kernel and initfs to be encrypted and hashed by the filesystem.
- relibc: Relibc has had constant various changes that have enabled the porting of more software, as well as fixing issues in many C programs and libraries. This work was incredibly varied and hard to summarize.
- rust: We now have a version of rustc that can run on Redox OS! There is still work to be done to improve the performance and to ensure cargo can run on Redox OS projects from inside Redox OS.
