[ ] So I’ve been using Linux for a very long time. I’ve been using Linux probably since I was 12 years old, maybe 10… And it has always been a stable and reliable operating system, and it’s always been thought of as a secure operating system, and in many ways it is. Any Linux-based operating system is more secure than Windows; that’s end of story, the truth. But there are flaws in the way that most Linux distributions handle security, and the way in which the Linux kernel itself handles security. There are about 400 system calls in Linux, whereas there are about 50 in Redox. Each one has, I would say, mathematical attributes around it in its use; in specific cases you use this specific syscall. It will not be duplicated. There won’t be another syscall that does the same thing. That kind of design already yields itself to more security, because you have less surface area.

Then, if you go further to some of the things we’re trying to do with OS-level virtualization and with schemes, what you have is a file system that can be reliably contained, whereas with Linux, any process running in any user level can access certain hardware devices, either through ioctl’s or through the dev file system, and most users have the ability to gain superuser access, at least what you run your browser as. In Redox all of the drivers run in user space, and all of the drivers run in a special container mode whereby they release privileges to access any hardware after they’ve gained access to the hardware that they need to control. What this means is that for example the disk driver will open the disk device, and then it will disable its ability to gain access to any other devices at any time in the future. A vulnerability in the disk driver now went from a privilege escalation allowing any system to be accessed, to a privilege escalation allowing the disk to be read and written. Just as bad, perhaps, you could rewrite things on disk, of course, you could rewrite the kernel, but you’ve contained that piece of functionality.

An even better example is a network stack. A network stack that gets compromised on Redox is only able to access the network device that it’s operating on. So it can send bad packets and it can lie about received packets. That’s it. Whereas if you have a network stack that’s compromised on Linux, it gains access to the entire kernel… Depending on how it’s compromised, of course, but there have been privilege escalations in the Linux kernel that have been remote vulnerabilities, that have allowed remote attackers through accessing the network devices of another machine, access to the kernel and running arbitrary code at a kernel level, which is clearly a worse vulnerability.

So firstly, the microkernel architecture divides devices into separate spaces; each one is in some process space. Secondly, OS-level virtualization prevents those processes from accessing any devices after they get into a working state. They open the devices they need, they disable their ability to access any more.

Thirdly, everything is written in Rust. I hate to have to go to that point, because I think – people who are on the fence about Rust, when you say “Well, you should rewrite it in Rust”, they will look back at you and they will ask “How will that improve my coding quality? How will that prevent logic errors? How will that prevent programmer failures that happen in Rust anyways?”, and it won’t. They’re right that Rust is not the magic bullet that people seem to keep pushing it as. Rust is simply one part of the puzzle. That’s why we have to have a microkernel design.

[ ] Some people have asked “Why not do a unikernel design? If everything’s written in Rust, it should be completely sane to have everything run in a kernel space, because you have protection from a language level.” It’s not true. It’s not true at all. Rust is not perfect. Rust cannot protect against every single vulnerability, and so in this method you need to have different levels. You need to have the microkernel for protecting device drivers and services, keeping them separate. You need to have OS-level containerization, so that processes run in an even more containerized form than by default. Not only do they have memory access being prevented across process spaces, but you also have file access being prevented across process spaces. And finally, Rust to protect against programmer error, to prevent (but not completely eliminate) the possibility of buffer overflows, of bad pointers, and of double frees and things like that. Those three together are the reason why Redox is potentially more secure.