User Tools

Site Tools


Reliability in MINIX 3

One of the main goals of MINIX 3 is reliability. Below we discuss some of the more important principles that enhance MINIX 3's reliability. These principles also enhance security, since most security flaws are due to attackers exploiting bugs in the code, so greater reliability will also improve security. Some of the ideas discussed are in the current release, but a few are scheduled for the next release. As this is a research project, we often make changes as we think of new ways to improve reliability.

Reduce kernel size

Monolithic operating systems (e.g., Windows, Linux, BSD) have millions of lines of kernel code. There is no way so much code can ever be made correct. In contrast, MINIX 3 has about 4000 lines of executable kernel code. We believe this code can eventually be made fairly close to bug free.

Cage the bugs

In monolithic operating systems, device drivers reside in the kernel. This means that when a new peripheral is installed, unknown, untrusted code is inserted in the kernel. A single bad line of code in a driver can bring down the system. This design is fundamentally flawed. In MINIX 3, each device driver is a separate user-mode process. Drivers cannot execute privileged instructions, change the page tables, perform I/O, or write to absolute memory. They have to make kernel calls for these services and the kernel checks each call for authority.

Limit drivers' memory access


Survive bad pointers


Tame infinite loops

If a driver gets into an infinite loop, the scheduler will gradually lower its priority until it becomes the idle process. Eventually the reincarnation server will see that it is not responding to status requests, so it will kill and restart the looping driver. In a monolithic system, a looping driver hangs the system.

Limit damage from buffer overruns


Restrict access to kernel functions


Restrict access to I/O ports


Restrict communication with OS components


Reincarnate dead or sick drivers

A special process, called the reincarnation server, periodically pings each device driver. If the driver dies or fails to respond correctly to pings, the reincarnation server automatically replaces it by a fresh copy. The detection and replacement of nonfunctioning drivers is automatic, without any user action required. This feature does not work for disk drivers at present, but in the next release the system will be able to recover even disk drivers, which will be shadowed in RAM. Driver recovery does not affect running processes.

Integrate interrupts and messages


www/documentation/reliability.txt · Last modified: 2014/11/19 11:12 by lionelsambuc