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.[2]
Minix 3 is believed to have inspired 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.[14][15] 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.[16]
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)[17] can bring down the whole system,[18] Minix 3 aims to create an operating system that is a "reliable, self-healing, multiserver Unix clone".[19]
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.[20]
Improved driver modularity: UDS separate from PFS, PTY from TTY, one controller per at_wini instance, LOG removed from boot image
Packages are now dynamically linked
3.4.0 rc6
2017-05-09
X11 is now part of the operating system.
Book Release
Old release
Current stable release
Current development release
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 new edition of Tanenbaum and Woodhull's textbook, 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.[23][24] In late 2005, the copyright owner was changed and a fourth clause was added.[1][25][28]
Reliability policies
One of the main goals of Minix 3 is reliability. Below, some of the more important principles that enhance its reliability are discussed.
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,[29] 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.
Instead, 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 file system, it builds a descriptor telling who has access and at what addresses. It then 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 have no effect on 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 also 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.
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 with a fresh copy. Detecting and replacing non-functioning drivers is automatic, with no user action needed. 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 random-access memory (RAM). Driver recovery does not affect running processes.
Integrate interrupts and messages
When an interrupt occurs, it is converted at a low level to a notification sent to the appropriate driver. If the driver is waiting for a message, it gets the interrupt immediately; otherwise it gets the notification the next time it does a RECEIVE to get a message. This scheme eliminates nested interrupts and makes driver programming easier.
Architecture
The architecture of Minix 3
As can be seen, at the bottom level is the microkernel, which is about 4,000 lines of code (mostly in C, plus a small amount of assembly language). It handles interrupts, scheduling, and message passing. It also supports an application programming interface (API) of about 30 kernel calls that authorized servers and drivers can make. User programs cannot make these calls. Instead, they can issue POSIXsystem calls which send messages to the servers. The kernel calls perform functions such as setting interrupts and copying data between address spaces.
At the next level up, there are the device drivers, each one running as a separate userland process. Each one controls some I/O device, such as a disk or printer. The drivers do not have access to the I/O port space and cannot issue I/O instructions directly. Instead, they must make kernel calls giving a list of I/O ports to write to and the values to be written. While there is a small amount of overhead in doing this (typically 500ns), this scheme makes it possible for the kernel to check authorization, so that, for example, the audio driver cannot write on the disk.
At the next level there are the servers. This is where nearly all the operating system functionality is located. User processes obtain file service, for example, by sending messages to the file server to open, close, read, and write files. In turn, the file server gets disk I/O performed by sending messages to the disk driver, which controls the disk.
One of the key servers is the reincarnation server. Its job is to poll all the other servers and drivers to check on their health periodically. If a component fails to respond correctly, or exits, or gets into an infinite loop, the reincarnation server (which is the parent process of the drivers and servers) kills the faulty component and replaces it with a fresh copy. In this way the system is automatically made self-healing without interfering with running programs.
Currently the reincarnation server, the process server, and the microkernel are part of the trusted computing base. If any of them fail, the system crashes. Nevertheless, reducing the trusted computing base from 3-5 million lines of code, as in Linux and Windows systems, to about 20,000 lines greatly enhances system reliability.[citation needed]
Diagram of the relationships between several Unix-like systems
Minix 1.0, 1.5, and 2.0 were developed as tools to help people learn about the design of operating systems.
Minix 1.0, released in 1987, was 12,000 lines of C and some x86 assembly language. Source code of the kernel, memory manager, and file system of Minix 1.0 are printed in the book. Tanenbaum originally developed Minix for compatibility with the IBM PC and IBM PC/ATmicrocomputers available at the time.
Minix 3 does the same, and provides a modern operating system with many newer tools and many Unix applications.[30] Prof. Tanenbaum once said:
Please be aware that MINIX 3 is not your grandfather's MINIX ... MINIX 1 was written as an educational tool ... MINIX 3 is that plus a start at building a highly reliable, self-healing, bloat-free operating system ... MINIX 1 and MINIX 3 are related in the same way as Windows 3.1 and Windows XP are: same first name.[19]
Many improvements have also been made in the structure of the kernel since the Minix 2 release, making the system more reliable.[31] Minix version 3.1.5 was released 5 Nov 2009. It contains X11, Emacs, vi, cc, GCC, Perl, Python, Almquist shell, Bash, Z shell, FTP client, SSH client, Telnet client, Pine, and over 400 other common Unix utility programs. With the addition of X11, this version marks the transition away from a text-only system. Another feature of this version, which will be improved in future ones, is the ability of the system to withstand device driver crashes, and in many cases having them automatically replaced without affecting running processes. In this way, Minix is self-healing and can be used in applications demanding high reliability.
Minix 3.2.0 was released in February 2012. This version has many new features, including the Clang compiler, experimental symmetric multiprocessing support, procfs and ext2fs filesystem support, and GNU Debugger (GDB). Several parts of NetBSD are also integrated in the release, including the bootloader, libc and various utilities and other libraries.[32]
Minix 3.3.0 was released in September 2014. This release is the first version to support the ARM architecture in addition to x86. It also supports a NetBSDuserland, with thousands of NetBSD packages running right out of the box.
GNU Hurd is a collection of microkernel servers written as part of GNU, for the GNU Mach microkernel. It has been under development since 1990 by the GNU Project of the Free Software Foundation, designed as a replacement for the Unix kernel, and released as free software under the GNU General Public License. When the Linux kernel proved to be a viable solution, development of GNU Hurd slowed, at times alternating between stasis and renewed activity and interest.
MINIX is a Unix-like operating system based on a microkernel architecture. Since version 2.0, it has been POSIX compliant.
In computer science, a microkernel is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system (OS). These mechanisms include low-level address space management, thread management, and inter-process communication (IPC).
A monolithic kernel is an operating system architecture with the entire operating system running in kernel space. The monolithic model differs from other architectures such as the microkernel in that it alone defines a high-level virtual interface over computer hardware. A set of primitives or system calls implement all operating system services such as process management, concurrency, and memory management.
Mach is a kernel developed at Carnegie Mellon University by Richard Rashid and Avie Tevanian to support operating system research, primarily distributed and parallel computing. Mach is often considered one of the earliest examples of a microkernel. However, not all versions of Mach are microkernels. Mach's derivatives are the basis of the operating system kernel in GNU Hurd and of Apple's XNU kernel used in macOS, iOS, iPadOS, tvOS, and watchOS.
An operating system (OS) is system software that manages computer hardware and software resources, and provides common services for computer programs.
ext2, or second extended file system, is a file system for the Linux kernel. It was initially designed by French software developer Rémy Card as a replacement for the extended file system (ext). Having been designed according to the same principles as the Berkeley Fast File System from BSD, it was the first commercial-grade filesystem for Linux.
QNX is a commercial Unix-like real-time operating system, aimed primarily at the embedded systems market.
DragonFly BSD is a free and open-source Unix-like operating system forked from FreeBSD 4.8. Matthew Dillon, an Amiga developer in the late 1980s and early 1990s and FreeBSD developer between 1994 and 2003, began working on DragonFly BSD in June 2003 and announced it on the FreeBSD mailing lists on 16 July 2003.
XNU is the computer operating system (OS) kernel developed at Apple Inc. since December 1996 for use in the Mac OS X operating system and released as free and open-source software as part of the Darwin OS, which, in addition to being the basis for macOS, is also the basis for Apple TV Software, iOS, iPadOS, watchOS, visionOS, and tvOS.
A kernel is a component of a computer operating system. A comparison of system kernels can provide insight into the design and architectural choices made by the developers of particular operating systems.
HelenOS is an operating system based on a multiserver microkernel design. The source code of HelenOS is written in C and published under the BSD-3-Clause license.
A hybrid kernel is an operating system kernel whose architecture attempts to combine aspects and benefits of microkernel and monolithic kernel architectures used in operating systems.
The Tanenbaum–Torvalds debate was a written debate between Andrew S. Tanenbaum and Linus Torvalds, regarding the Linux kernel and kernel architecture in general. Tanenbaum, the creator of Minix, began the debate in 1992 on the Usenet discussion group comp.os.minix, arguing that microkernels are superior to monolithic kernels and therefore Linux was, even in 1992, obsolete. The debate has sometimes been considered a flame war.
Linux is a family of open-source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991, by Linus Torvalds. Linux is typically packaged as a Linux distribution (distro), which includes the kernel and supporting system software and libraries — many of which are provided by the GNU Project — to create a complete operating system.
Linux began in 1991 as a personal project by Finnish student Linus Torvalds to create a new free operating system kernel. The resulting Linux kernel has been marked by constant growth throughout its history. Since the initial release of its source code in 1991, it has grown from a small number of C files under a license prohibiting commercial distribution to the 4.15 version in 2018 with more than 23.3 million lines of source code, not counting comments, under the GNU General Public License v2 with a syscall exception meaning anything that uses the kernel via system calls are not subject to the GNU GPL.
The kernel is a computer program at the core of a computer's operating system and generally has complete control over everything in the system. The kernel is also responsible for preventing and mitigating conflicts between different processes. It is the portion of the operating system code that is always resident in memory and facilitates interactions between hardware and software components. A full kernel controls all hardware resources via device drivers, arbitrates conflicts between processes concerning such resources, and optimizes the utilization of common resources e.g. CPU & cache usage, file systems, and network sockets. On most systems, the kernel is one of the first programs loaded on startup. It handles the rest of startup as well as memory, peripherals, and input/output (I/O) requests from software, translating them into data-processing instructions for the central processing unit.
NetBSD is a free and open-source Unix-like operating system based on the Berkeley Software Distribution (BSD). It was the first open-source BSD descendant officially released after 386BSD was forked. It continues to be actively developed and is available for many platforms, including servers, desktops, handheld devices, and embedded systems.
The NetBSD rump kernel is the first implementation of the "anykernel" concept where drivers either can be compiled into or run in the monolithic kernel or in user space on top of a light-weight kernel. The NetBSD drivers can be used on top of the rump kernel on a wide range of POSIX operating systems, such as the Hurd, Linux, NetBSD, DragonFly BSD, Solaris kernels and even Cygwin, along with the file system utilities built with the rump libraries. The rump kernels can also run without POSIX directly on top of the Xen hypervisor, an L4 microkernel using the Genode OS Framework or even on OS-less bare metal.
↑ Tanenbaum, Andy (2006-09-25). "Introduction to MINIX 3". OSnew. OSnews. Retrieved 2008-07-04. From Rebirth section: "Various studies have shown that software broadly contains something like 6-16 bugs per 1000 lines of code and that device drivers have 3-7 times as many bugs as the rest of the operating system. When combined with the fact that 70% of a typical operating system consists of device drivers, it is clear that device drivers are a big source of trouble. For Windows XP, 85% of the crashes are due to bugs in device drivers. Obviously, to make OSes reliable, something has to be done to deal with buggy device drivers. Building a reliable system despite the inevitable bugs in device drivers was the original driving force behind Minix 3."
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
