Thought Experiment with Redox OS
In conversation with a Rust fanatic, we stumbled into the topic of operating systems. RedoxOS is an operating system written in Rust, from scratch. Everything is in rust, the core libraries, the kernel, the device modules/drivers, everything is rust through and through. It’s a microkernel design, which means the core kernel is pretty minimal. And everything else runs in user space and not in kernel space. Sidestepping the discussion of monolithic versus microkernel, Redox chose a microkernel for simplicity and security properties.
The idea in dscussion is about what possible futures there could be for an entire operating system written in Rust. The proposed points are:
- Written in a memory-safe language which removes an entire class of attacks against the OS.
- A fresh start using modern, operating system and development, techniques.
- A functional system which can be used for teaching the next generation of students.
- It’s freakin’ cool.
Point One
“Written in a memory-safe language which removes an entire class of attacks against the OS.”
We both agreed that Rust is fast, encourages safety and security as part of the core language, and right now it’s still evolving. Time will tell how accurate these claims are at face value. However why rust? is a fine summary. There’s nothing inherently wrong with C per se, it gives the developer a lot of freedom in managing memory and achieving desired performance levels on low end hardware. However, it’s been show over the decades that this freedom comes a cost of developer brainpower and their ability (en masse) to make it difficult to address a slew of issues; such as buffer overflows, memory safety, etc.
Point Two
“A fresh start using modern, operating system and development, techniques.”
This is where the bulk of the discussion lay. Over the past 40-50 years of general purpose operating systems, we’ve learned a lot about what works and what does not work. The current RedoxOS system runs on fairly standard hardware. Say you wanted it to run on your current computer (desktop, laptop, phone, etc), what would it need? The biggest thing is to make sure the kernel works with your CPU, memory controller, and basics like that. The second biggest item is to support your devices. Almost all devices ship with either a software development kit (SDK) written in C, and/or the specifications of the hardware so you can write the code to interfaces with the hardware.
This is where linux, windows, and macosx shine. It’s an easy sell to produce a device (controller, mouse, video card, etc) that has a module/driver written in C and provides an interface library to the main OS. The developers of whichever OS you like then write the code to handle the device and the operating system interfaces. Windows, Linux, and OSX have thousands of developers working to make all devices work with your hardware. Redox needs to develop all of these drivers themselves, in Rust. It’s a huge task. Alternatively, Redox could have a C to Rust interface or interpreter to using exsting modules in a sandbox. However, then you don’t have a pure Rust system. This is for general purpose computing.
Take a smaller subset of computing and think about that for a bit. Let’s take a specialized need and apply RedoxOS to it. For this case, we’re going to take point of sale (PoS) devices (cash registers in other words). You are a new upstart PoS provider who wants to develop a product based on a secure platform. You take a system on a chip (SoC) and figure out the power, processing, and memory needed to put into a board to sell in a case with a screen as your new PoS device. In this case, your core computing environment is known and controlled. Your peripherals (credit card reader, NFC tap to pay, user screen, and maybe barcode reader) are all well defined. You can get the SDK or the specs from the supplier or chip designer and pay people to write the modules in Rust, from scratch. This is a more manageable situation for the RedoxOS developer employed at the PoS startup. Now you can legitimately advertise that your PoS system is more secure because of the reliance on Rust end to end.
In the larger picture, back to general computing. You could design a laptop, desktop, or phone with specific hardware which has the modules for the devices written in Rust. Users cannot swap hardware around because then RedoxOS won’t have anyway to know how to interface with the device. System76 is taking the first step by writing a new desktop environment called cosmic in Rust.
Point Three
“A functional system which can be used for teaching the next generation of students.”
Generations of developers have started and finished school learning C. If you need performance and to manage memory or interface with hardware, you learn C in school. I learned C in school for this reason. Higher level languges, like Perl, Python, Ruby, Pascal, etc have all been taught to solve different problems. No one tries to write an operating system in Python. I’m sure someone has somewhere, but maybe it was for a thought experiment.
MINIX was written in C to teach students about operating system concepts. It was taught so well that one student, Linus Torvalds, happened to write his own OS in C, based on MINIX, called Linux. I’m sidestepping the nuances of the kernel versus the rest of the operating system on purpose here. Otherwise, we’d have a 500 page post.
RedoxOS is not the first OS written in Rust and not the first Rust-based OS to be taught in school. However, now that it’s a functioning OS, it can be taught to generations of students to come.
It’s not like Linux and other operating systems have stood still either. Linux builds on decades of UNIX systems. At the time Linux was first released, it was the new player and considered a toy OS. Mainframes were around even longer. Current linux developers have been through modern schools and have learned modern ways of development and operating systems theories.
The challenge with a successful track record and multi-decade history is that you have to either break backwards compatibility or continue to carry forward every past design decision. With a fresh start, you can start from nothing and decide what is supported or not. And with a young OS, you can change your mind without causing much chaos.
Point Four
“It’s freakin’ cool.”
Yes it is. Download it. Install it to a virtual machine or liveboot the USB live system and play around with it. It’s fast, usable, and likely the future.