Redox: a Rust-based microkernel

Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

Creating a new operating system from scratch is a daunting task—witness the slow progress of GNU Hurd, for example. But it would be hard to argue that the existing systems are the be-all and end-all of how we interact with computer hardware. At least some of the deficiencies in today's offerings can arguably be traced to the language used to implement them; C, for all its power, has some fairly serious flaws that lead to bugs and security holes of various sorts. So it is interesting to see a new entrant that uses the Rust language, which is focused on memory safety. The result is Redox, which is still far from ready for everyday use, but may provide an interesting counterpoint to Linux, the BSDs, OS X, Windows, and others.

As laid out in the Redox book (which is also a work in progress), Rust was chosen for its memory and type safety. Some of those features were described in an LWN article back in 2013. The Redox developers see these safety features as a critical part of a modern operating system, even one that is based on the much-older Unix model:

However, we have an advantage: enforced memory and type safety. This is Rust's strong side, a large number of "unexpected bugs" (for example, undefined behavior) are eliminated. The design of Linux and BSD is secure. The implementation is not.

So the goal is to eliminate whole classes of problems that plague C programs, but the focus on security doesn't stop there. Unlike Linux, Redox has a microkernel design, where much of the code that resides in a monolithic kernel like Linux is moved to user space. A microkernel simply provides resource management, interprocess communication (IPC), process/thread management and scheduling, system calls, and little else. The result is a much smaller kernel (16,000 lines of code for Redox and plans to reduce that further) with a concomitant reduction in the attack surface, as well as a much smaller amount of critical kernel code to audit.

In Redox, as in MINIX that it is partly patterned after, drivers live in user space so they can do far less damage when they fail. In monolithic kernels, a bad driver can crash the whole system because it runs in the kernel's address space and with its privilege level. So, for Redox, filesystems, device drivers, networking, and so on are all implemented in user space.

Beyond that, Redox has taken the Unix "everything is a file" philosophy (which was further expanded by Plan 9) and taken it a step further. In Redox, everything is a URL (or, really, a URI), which means that the API is based on using URLs to access local and remote resources: files, networking protocols and sites, devices, and so forth.

The "scheme" portion of a URI (e.g. the "http:" in a web URL) is used to identify the type of the resource being accessed. These are implemented as Redox schemes, which can be implemented in user space or the kernel, though user space is preferred. Schemes are effectively virtual filesystems with a set of operations made available that are appropriate to the type. As the book notes: "'Everything is a scheme, identified by an URL' is more accurate, but not very catchy."

The Redox wiki goes into a bit more detail of how URLs and schemes are used. For example, tcp://10.11.12.13:80 would be used for a remote TCP connection, while file:/apps/terminal/example.txt refers to a local file. In the networking wiki page, there is mention of using a URL like tcp:///80 for a web server or ethernet://12:34:56:78:9A:BC/800 to receive or send IPv4 (type 800) packets for the specified MAC address.

Underneath the schemes are resources, which come in two flavors: file-like (i.e. blocking and buffered) and socket-like (i.e. non-blocking and stream-like). Resources are closely related to schemes, as the book notes:

Resources are opened schemes. You can think of them like an established connection between the scheme provider and the client. Resources are closely connected to schemes, and are sometimes intertwined with schemes. The difference between them is subtle, yet crucial.

While the kernel is the main focus of the project currently, there are some side projects of interest as well. To start with, ZFS is planned as the filesystem of choice for Redox, which means writing a compatible implementation in Rust or adapting the existing open-source version (OpenZFS). There is a minimal graphics server, orbital, that is based on the Wayland protocol. There is also a vi-like editor (Sodium), games, and more.

The code is available on GitHub and has been released under the MIT license. The explanation for choosing the MIT license has been somewhat controversial among some GPL advocates, but the developers clearly want Redox to spread far and wide—proprietary forks and extensions are explicitly condoned. ISO images for various targets are available, though they are yet another work in progress. The book also has some instructions (starting here) for those who want to build Redox for themselves.

A Discourse forum is provided to discuss Redox and its development. There are contribution guidelines and ideas, a best practices page, and the inevitable issues list as well. Those interested can keep up with the project by checking out the "This Week in Redox" newsletters, though they are rather more sporadic than the name would imply. The Code of Conduct is fairly extensive and clearly shows an intent to foster an inclusive community. In short, there is quite a bit of information available about Redox, though it is somewhat scattered.

One question that many will ask is "why a new operating system?" The Redox developers have an answer that boils down to dissatisfaction with Linux, the BSDs, and, even, MINIX (which is "the most in line with Redox's philosophy"). There is an admitted "Not Invented Here" sentiment within the project. But one thing that is explicitly not a goal for the project is replacing Linux. A one-word answer ("No") to the "will Redox replace Linux?" question is contained in the book.

That's probably a good thing for a number of reasons. For one thing, hardware support is a huge task that is unlikely to be surmounted without an enormous effort from lots of companies—something that the MIT license might make difficult. Like it or not, the reciprocal nature of the GPL certainly seems to be a driving force for the corporate involvement in Linux. It is also an area where more permissively licensed alternatives (the BSDs and MINIX) have run aground to some extent.

But there are other hurdles as well. Redox has deliberately chosen to implement a minimal subset of the Linux (and POSIX) system calls. That will make it more difficult to port existing applications to Redox. That is partly by design, however, as a Rust-based user-space ecosystem is envisioned, but the huge number of existing freely licensed applications, which may be difficult to port, could be a big impediment to Redox adoption. Longstanding issues with the performance of microkernels (which require many more context switches than monolithic kernels do) may also make Redox a hard sell for the more lucrative server segment—though performance for desktops may turn out to be reasonable, especially if the security gains are substantial.

It is clearly an ambitious project—perhaps even overly ambitious; only time will tell. It does bear watching, though, as an experiment in several dimensions. The microkernel design and Rust-based implementation will provide answers (or at least evidence in one direction or another) to some questions that have been floating around for some time. We clearly don't have all the operating system answers for the future, so more data is called for. Redox might just provide some of that data.