Minix 3 is a small, Unix-like operating system published under a BSD-3-Clause license, and is a successor project to the earlier versions, Minix 1.x and 2.0. The project's main goal is for the system to be fault-tolerant by detecting and repairing its faults on the fly, with no user intervention. The main uses of the system are envisaged to be embedded systems and education. As of 2017, Minix 3 supports IA-32 and ARM architecture processors. It can also run on emulators or virtual machines, such as Bochs, VMware Workstation, Microsoft Virtual PC, Oracle VirtualBox, and QEMU. A port to PowerPC architecture is in development. The distribution comes on a live CD and does not support live USB installation. The project has been dormant since late 2018, and the latest release is 3.4.0 rc6 from 2017, although the Minix 3 discussion group is still active. Minix 3 is the Intel Management Engine (ME) OS found in Intel's Platform Controller Hub, starting with the introduction of ME 11, which is used with Skylake and Kaby Lake processors. It was debated that Minix could have been the most widely used OS on x86/AMD64 processors, with more installations than Microsoft Windows, Linux, or macOS, because of its use in the Intel ME.
Goals of the project
Reflecting on the nature of monolithic kernel–based systems, where a driver (which has, according to Minix creator Tanenbaum, approximately 3–7 times as many bugs as a usual program) can bring down the whole system, Minix 3 aims to create an operating system that is a "reliable, self-healing, multiserver Unix clone". To achieve that, the code running in kernel must be minimal, with the file server, process server, and each device driver running as separate user-mode processes. Each driver is carefully monitored by a part of the system named the reincarnation server. If a driver fails to respond to pings from this server, it is shut down and replaced by a fresh copy of the driver. In a monolithic system, a bug in a driver can easily crash the whole kernel. This is far less likely to occur in Minix 3.
History
Minix 3 was publicly announced on 24 October 2005 by Andrew Tanenbaum during his keynote speech on top of the Association for Computing Machinery (ACM) Symposium Operating Systems Principles conference. Although it still serves as an example for the third edition of Tanenbaum and Woodhull's textbook (2006), it is comprehensively redesigned to be "usable as a serious system on resource-limited and embedded computers and for applications requiring high reliability." Initially released under the same BSD-3-Clause license that Minix was licensed under since 2000, in late 2005, the copyright owner was changed and a fourth clause was added.
Reliability policies One of the main goals of Minix 3 is reliability. Below are some of the more important principles that enhance its reliability.
Reduce kernel size Monolithic operating systems such as Linux and FreeBSD and hybrids like Windows have millions of lines of kernel code. In contrast, Minix 3 has about 6,000 lines of executable kernel code, which can make problems easier to find in the code.
Cage the bugs In monolithic kernels, device drivers reside in the kernel. Thus, when a new peripheral is installed, unknown, untrusted code is inserted in the kernel. One bad line of code in a driver can bring down the system. In contrast, in Minix 3, each device driver is a separate user-mode process. Drivers cannot execute privileged instructions, change the page tables, perform arbitrary input/output (I/O), or write to absolute memory. They must make kernel calls for these services and the kernel checks each call for authority.
Limit drivers' memory access In monolithic kernels, a driver can write to any word of memory and thus accidentally corrupt user programs. In Minix 3, when a user expects data from, for example, the MINIX file system, it builds a descriptor telling who has access and at what addresses. It passes an index to this descriptor to the file system, which may pass it to a driver. The file system or driver then asks the kernel to write via the descriptor, making it impossible for them to write to addresses outside the buffer.
Survive bad pointers Dereferencing a bad pointer within a driver will crash the driver process, but will not affect the system as a whole. The reincarnation server will restart the crashed driver automatically. Users will not notice recovery for some drivers (e.g., disk and network) but for others (e.g., audio and printer), they might. In monolithic kernels, dereferencing a bad pointer in a driver normally leads to a system crash.
Tame infinite loops If a driver gets into an infinite loop, the scheduler will gradually lower its priority until it becomes idle. 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 kernel, a looping driver could hang the system.
Limit damage from buffer overflows Minix 3 uses fixed-length messages for internal communication, which eliminates certain buffer overflows and buffer management problems. Also, many exploits work by overrunning a buffer to trick the program into returning from a function call using an overwritten stack return address pointing into attacker controlled memory, usually the overrun buffer. In Minix 3, this attack is mitigated because instruction and data space are split and only code in (read-only) instruction space can be executed, termed executable-space protection. However, attacks which rely on running legitimately executable memory in a malicious way (return-to-libc, return-oriented programming) are not prevented by this mitigation.
Restrict access to kernel functions Device drivers obtain kernel services (such as copying data to users' address spaces) by making kernel calls. The Minix 3 kernel has a bit map for each driver specifying which calls it is authorized to make. In monolithic kernels, every driver can call every kernel function, authorized or not.
Restrict access to I/O ports The kernel maintains a table telling which I/O ports each driver may access. Thus, a driver can only touch its own I/O ports. In monolithic kernels, a buggy driver can access I/O ports belonging to another device.
Restrict communication with OS components Not every driver and server needs to communicate with every other driver and server. Accordingly, a per-process bit map determines which destinations each process may send to.
… excerpt ends here. Continue reading the full article.
