Unix-like operating system
Operating system
Minix 3
is a small,
Unix-like
operating system
. It is published under a
BSD-3-Clause
[a]
license and is a successor project to the earlier versions,
Minix
1 and 2.
[1]
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]
As of 2017
[update]
, Minix 3 supports
IA-32
and
ARM architecture
processors.
[3]
It can also run on
emulators
or
virtual machines
, such as
Bochs
,
[4]
[5]
VMware Workstation
,
[6]
Microsoft Virtual PC
,
[7]
Oracle
VirtualBox
,
[8]
and
QEMU
. A port to
PowerPC
architecture is in development.
[9]
The distribution comes on a
live CD
and does not support
live USB
installation.
[10]
The project has been dormant since 2018,
[11]
and the latest release is 3.4.0 rc6 from 2017,
[12]
although the Minix 3 discussion group is still active.
[13]
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]
Goals of the project
[
edit
]
Structure of
monolithic kernel
and
microkernel
-based operating systems, respectively
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]
History
[
edit
]
MINIX 3 versions
[21]
[22]
Version
|
Release date
|
Description
|
3.1.0
(
OSDI3
)
|
2005-10-18
|
|
3.1.1
(SOSP)
|
2005-10-24
|
|
3.1.2
|
2006-04-18
|
|
3.1.2a
|
2006-05-29
|
- New Packman package manager.
- Fixed an installation issue with auto-partitioning disks.
|
3.1.3
|
2007-04-13
|
|
3.1.3a
|
2007-06-08
|
|
3.1.4
|
2009-06-09
|
|
3.1.5
|
2009-11-05
|
- Improvements performance
- Shared memory
- setitimer function
- ISO 9660
file system
- Open Sound System
- Trap NULL accesses now, for user convenience
- Improved signal handling
- Better support for debuggers (
ptrace
improvements, etc.)
- Network card autodetection (for supported
PCI cards
), improved network configuration
|
3.1.6
|
2010-02-08
|
- New Network drivers: Atheros L2, Intel E1000, Realtek 8169, DEC Tulip
- PipeFS ? removed pipe handling from filesystem drivers
- HGFS ? support for mounting
VMware shared folders
as
file system
- VFS: supplemental group support and
sticky bit
support
- Floating-point unit
support
- System Event Framework (SEF)
- Experimental
APIC
support
|
3.1.7
|
2010-06-16
|
- Userspace scheduling and a scheduling server
[26]
- Proper support for multiple Ethernet cards of the same type
- Boot monitor allows loading images > 16 MB
- Buildsystem support for building Minix with
GCC
- Support for
Windows-1251
and
KOI8-U
charsets
|
3.1.8
|
2010-10-04
|
|
3.2.0
|
2012-02-29
|
- Porting
GNU Debugger
to Minix 3 and implementing core dumping support
- FUSE
support with experimental
NTFS-3G
file system
- Gradually replacing
userland
, from Minix to
NetBSD
- Replacing the default compiler
ACK
with
Clang
;
GCC
is also supported
- Switch to
ELF
and NetBSD
libc
libraries
- Pkgsrc upstreaming and application porting
- Asynchronous
virtual filesystem
(VFS) server
- Replacing the bootloader from Minix to
NetBSD
- NCQ
support in the
AHCI
driver
|
3.2.1
|
2013-02-21
|
|
3.3.0
[27]
|
2014-09-15
|
- ARM architecture support; cross-compilable
- Support for
mmap()
I/O mechanism; allows for shared dynamic libraries and lower memory needs
- New input infrastructure: input server and keyboard driver separated from TTY
- VND: vnode disk (loopback) block driver
- LLVM
Bitcode build of the system
- Import of
LLVM
and
clang
in the sources
- Unified block cache shared by FSes and VM
- Improved NetBSD compatibility: utilities, calls, types (lots of 64-bit), toolchain, codebase, and packages
- C type for messages: cleaner, bigger
[
clarification needed
]
- 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.
|
|
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
[
edit
]
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
POSIX
system 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 500 ns), 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
]
Differences between Minix 3 and prior versions
[
edit
]
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/AT
microcomputers
available at the time.
Minix 1.5, released in 1991, included support for
MicroChannel
IBM PS/2
systems and was also ported to the
Motorola 68000
and
SPARC
architectures, supporting the
Atari ST
,
Commodore
Amiga
, Apple
Macintosh
and
Sun Microsystems
SPARCstation
computer platforms. A version of Minix running as a user process under
SunOS
was also available.
Minix 2.0, released in 1997, was only available for the
x86
and
Solaris
-hosted SPARC architectures.
Minix-vmd
was created by two
Vrije Universiteit
researchers, and added
virtual memory
and support for the
X Window System
.
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
NetBSD
userland
, with thousands of NetBSD packages running right out of the box.
Mascot
[
edit
]
Rocky Raccoon, the mascot of Minix 3.
Rocky Raccoon
is the mascot of Minix 3.
[33]
MINIXCon
[
edit
]
MINIXCon is a conference on sharing talks, efforts and researches related to Minix.
It was held once in 2016. MINIXCon2017 was cancelled due to lack of talks submitted.
[34]
[35]
See also
[
edit
]
Notes
[
edit
]
- ^
a
b
c
BSD-3-Clause with a fourth clause.
References
[
edit
]
- ^
a
b
c
"The Minix license"
. Archived from
the original
on 2005-11-24
. Retrieved
2005-11-24
.
- ^
corbet (2005-10-24).
"Minix 3 hits the net"
. Lwn.net
. Retrieved
2014-05-01
.
- ^
"minix3.org"
. minix3.org
. Retrieved
2017-04-16
.
- ^
"Getting Started with Minix on Bochs on Mac OS"
. Woodhull.com
. Retrieved
2014-05-01
.
- ^
"OSNews.com"
. OSNews.com
. Retrieved
2014-05-01
.
- ^
"Minix under VMWare Installation How-To"
. Patrick.wagstrom.net. Archived from
the original
on 2013-11-12
. Retrieved
2014-05-01
.
- ^
"Minix on Virtual PC: first look"
. Woodhull.com
. Retrieved
2014-05-01
.
- ^
"Minix 3 on Virtual box"
. inopinion.org. 6 August 2014.
- ^
Alting, Ingmar.
"A port of the MINIX OS to the PowerPC platform"
(PDF)
.
- ^
"Minix3"
. Minix3
. Retrieved
2014-05-01
.
- ^
"git.minix3.org Git - minix.git/summary"
.
git.minix3.org
. Retrieved
2022-05-03
.
- ^
"Index of /Iso/Snapshot/"
.
- ^
"minix3 - Google Groups"
.
groups.google.com
. Retrieved
2022-05-03
.
- ^
"Intel ME: The Way of Static Analysis"
.
blog.ptsecurity.com
. Archived from
the original
on 2017-07-01
. Retrieved
2017-08-28
.
- ^
Corna, Nicola (2017-08-28).
"me_cleaner: Tool for partial deblobbing of Intel ME/TXE firmware images"
.
GitHub
. Retrieved
2017-08-28
.
- ^
Tanenbaum, Andrew S.
"An Open Letter to Intel"
.
Archived
from the original on 2022-06-17
. Retrieved
2022-09-06
.
- ^
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."
- ^
"CSAIL Event Calendar"
. Csail.mit.edu. Archived from
the original
on 2012-02-04
. Retrieved
2014-05-01
.
- ^
a
b
"Tanenbaum-Torvalds debate, Part II"
. Cs.vu.nl. 2006-05-12
. Retrieved
2014-05-01
.
- ^
"Reliability"
.
www.MINIX3.org
. Archived from
the original
on July 1, 2006.
- ^
"MinixReleases ? Minix Wiki"
. Wiki.minix3.org
. Retrieved
2014-05-01
.
- ^
"Minix versions and their use in teaching"
. Archived from
the original
on 2006-07-11
. Retrieved
2021-06-16
.
- ^
a
b
"LICENSE (3.1.0)"
.
GitHub
. Retrieved
2021-06-16
.
- ^
a
b
"LICENSE (3.1.1)"
. Retrieved
2021-06-16
.
- ^
a
b
"LICENSE (3.1.2)"
.
GitHub
. Retrieved
2021-06-16
.
- ^
Swift, Bjorn Patrick.
"Individual Programming Assignment User Mode Scheduling in Minix 3"
(PDF)
. Minix3.org.
- ^
MINIX Release 3.3.0
- ^
"Minix1: Copying and Use Policies"
. 2007-02-13.
Archived
from the original on 2020-06-14.
- ^
"The MINIX 3 Operating System"
.
minix3.org
. Archived from
the original
on 2012-01-13.
- ^
"FAQ ? Minix Wiki"
. Minix3.org. 2013-11-09
. Retrieved
2014-05-01
.
- ^
"Improvements since V2"
.
www.minix3.org
. Archived from
the original
on April 17, 2006.
- ^
"MINIX Releases"
.
wiki.minix3.org
. Archived from
the original
on 21 June 2012
. Retrieved
29 February
2012
.
- ^
"mascot [Wiki]"
.
wiki.minix3.org
. Retrieved
2017-07-20
.
- ^
"Minix3"
. Archived from the original on 10 November 2017
. Retrieved
5 July
2006
.
{{
cite web
}}
: CS1 maint: bot: original URL status unknown (
link
)
- ^
"Minix3"
.
www.minix3.org
. Retrieved
2017-11-11
.
Further reading
[
edit
]
- Tanenbaum, Andrew S
; Woodhull, Albert S. (14 January 2006).
Operating Systems: Design and Implementation
(3rd ed.).
Prentice Hall
.
ISBN
0-13-142938-8
.
- Building a dependable operating system: fault tolerance in MINIX 3
by Jorrit N. Herder (PDF)
- Reorganizing Unix for Reliability
by Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum (PDF)
- Modular system programming in MINIX 3
by Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S Tanenbaum (PDF)
- J. N. Herder et al.,
Modular System Programming in MINIX 3
,
;Login
, April 2006
(PDF)
- Pablo A Pessolani.
MINIX4RT: A Real-Time Operating System Based on MINIX
Archived
2023-06-07 at the
Wayback Machine
- Building Performance Measurement Tools for the MINIX 3 Operating System
, by Rogier Meurs
(PDF)
- Design and implementation of the MINIX virtual file system
(PDF)
- Reference manual for MINIX 3 Kernel API
(PDF)
- Towards a true microkernel operating system
(PDF)
- Construction of a Highly Dependable Operating System
(PDF)
- Minix 3 and the microkernel experience: Smart Kernel
by Rudiger Weis (PDF)
- Safe and Automatic Live Update
by Cristiano Giuffrida (PDF)
External links
[
edit
]
Wikibooks has a book on the topic of:
Minix 3