Jump to content

Minix 3

From Wikipedia, the free encyclopedia
Minix 3
Minix 3 runningX11withtwmas Window Manager
DeveloperAndrew S. Tanenbaumet al.
Written inC,assembly language
OS familyUnix-like
Working stateAbandoned
Source modelOpen source
Initial release24 October 2005;18 years ago(2005-10-24)
Latest release3.3.0 / September 16, 2014;9 years ago(2014-09-16)
Latest preview3.4.0 rc6 / May 9, 2017;7 years ago(2017-05-09)
Repository
Marketing targetEmbedded systems,education
Available inEnglish
PlatformsIA-32,ARM
KerneltypeMicrokernel
UserlandMinix,NetBSD
Default
user interface		ash
License2005:BSD-3-Clause[a][1]
Original:BSD-3-Clause
Preceded byMinix1.0, 1.5 and 2.0
Official websitewww.minix3.org

Minix 3is a small,Unix-likeoperating system.It is published under aBSD-3-Clause[a]license and is a successor project to the earlier versions,Minix1 and 2.[1]

The project's main goal is for the system to befault-tolerantby detecting and repairing its faults on the fly, with no user intervention. The main uses of the system are envisaged to beembedded systemsand education.[2]

As of 2017,Minix 3 supportsIA-32andARM architectureprocessors.[3]It can also run onemulatorsorvirtual machines,such asBochs,[4][5]VMware Workstation,[6]Microsoft Virtual PC,[7]OracleVirtualBox,[8]andQEMU.A port toPowerPCarchitecture is in development.[9]The distribution comes on alive CDand does not supportlive USBinstallation.[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 theIntel Management Engine(ME) OS found in Intel'sPlatform Controller Hub,starting with the introduction of ME 11, which is used withSkylakeandKaby Lakeprocessors.[14][15]It was debated that Minix could have been the most widely used OS onx86/AMD64processors, with more installations than Microsoft Windows, Linux, ormacOS,because of its use in the Intel ME.[16]

Goals of the project[edit]

Structure ofmonolithic kernelandmicrokernel-based operating systems, respectively

Reflecting on the nature ofmonolithic kernelbased systems, where a driver (which has, according to Minix creatorTanenbaum,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 thereincarnation 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
  • Bug fixes.
3.1.4 2009-06-09
3.1.5 2009-11-05
  • Improvements performance
  • Shared memory
  • setitimer function
  • ISO 9660file system
  • Open Sound System
  • Trap NULL accesses now, for user convenience
  • Improved signal handling
  • Better support for debuggers (ptraceimprovements, etc.)
  • Network card autodetection (for supportedPCI cards), improved network configuration
3.1.6 2010-02-08
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 withGCC
  • Support forWindows-1251andKOI8-Ucharsets
3.1.8 2010-10-04
3.2.0 2012-02-29
3.2.1 2013-02-21
3.3.0[27] 2014-09-15
  • ARM architecture support; cross-compilable
  • Support formmap()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
  • LLVMBitcode build of the system
  • Import ofLLVMandclangin 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.
  • 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 theAssociation 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 sameBSD-3-Clauselicense 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 asLinuxandFreeBSDand hybrids likeWindowshave millions of lines ofkernelcode. 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 driversreside 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 thepage tables,perform arbitraryinput/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 badpointerwithin 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 aninfinite 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 certainbuffer overflowsand 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, termedexecutable 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 obtainkernel 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 whichI/O portseach 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 inrandom-access memory(RAM). Driver recovery does not affect running processes.

Integrate interrupts and messages[edit]

When aninterruptoccurs, 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 aRECEIVEto 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 themicrokernel,which is about 4,000 lines of code (mostly inC,plus a small amount ofassembly language). It handlesinterrupts,scheduling,and message passing. It also supports anapplication programming interface(API) of about 30 kernel calls that authorized servers and drivers can make. User programs cannot make these calls. Instead, they can issuePOSIXsystem callswhich 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 thedevice drivers,each one running as a separateuserlandprocess. 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 theservers.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 aninfinite 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 thetrusted 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]

Main article:Minix
Diagram of the relationships between several Unix-like systems

Minix1.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 ofCand some x86assembly language.Source code of the kernel,memory manager,andfile systemof Minix 1.0 are printed in the book. Tanenbaum originally developed Minix for compatibility with theIBM PCandIBM PC/ATmicrocomputersavailable at the time.

Minix 1.5, released in 1991, included support forMicroChannelIBM PS/2systems and was also ported to theMotorola 68000andSPARCarchitectures, supporting theAtari ST,CommodoreAmiga,AppleMacintoshandSun MicrosystemsSPARCstationcomputer platforms. A version of Minix running as a user process underSunOSwas also available.

Minix 2.0, released in 1997, was only available for thex86andSolaris-hosted SPARC architectures.Minix-vmdwas created by twoVrije Universiteitresearchers, and addedvirtual memoryand support for theX Window System.

Minix 3 does the same, and provides a modern operating system with many newer tools and manyUnixapplications.[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 asWindows 3.1andWindows XPare: 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 containsX11,Emacs,vi,cc,GCC,Perl,Python,Almquist shell,Bash,Z shell,FTP client,SSH client,Telnetclient,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 theClangcompiler, experimentalsymmetric multiprocessingsupport,procfsandext2fsfilesystem support, andGNU Debugger(GDB). Several parts ofNetBSDare also integrated in the release, including the bootloader,libcand variousutilitiesand otherlibraries.[32]

Minix 3.3.0 was released in September 2014. This release is the first version to support theARM architecturein addition to x86. It also supports aNetBSDuserland,with thousands of NetBSD packages running right out of the box.

Mascot[edit]

Rocky Raccoon, the mascot of Minix 3.

Rocky Raccoonis 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]

  1. ^abcBSD-3-Clause with a fourth clause.

References[edit]

  1. ^abc"The Minix license".Archived fromthe originalon 2005-11-24.Retrieved2005-11-24.
  2. ^corbet (2005-10-24)."Minix 3 hits the net".Lwn.net.Retrieved2014-05-01.
  3. ^"minix3.org".minix3.org.Retrieved2017-04-16.
  4. ^"Getting Started with Minix on Bochs on Mac OS".Woodhull.Retrieved2014-05-01.
  5. ^"OSNews".OSNews.Retrieved2014-05-01.
  6. ^"Minix under VMWare Installation How-To".Patrick.wagstrom.net. Archived fromthe originalon 2013-11-12.Retrieved2014-05-01.
  7. ^"Minix on Virtual PC: first look".Woodhull.Retrieved2014-05-01.
  8. ^"Minix 3 on Virtual box".inopinion.org. 6 August 2014.
  9. ^Alting, Ingmar."A port of the MINIX OS to the PowerPC platform"(PDF).
  10. ^"Minix3".Minix3.Retrieved2014-05-01.
  11. ^"git.minix3.org Git - minix.git/summary".git.minix3.org.Retrieved2022-05-03.
  12. ^"Index of /Iso/Snapshot/".
  13. ^"minix3 - Google Groups".groups.google.Retrieved2022-05-03.
  14. ^"Intel ME: The Way of Static Analysis".blog.ptsecurity.Archived fromthe originalon 2017-07-01.Retrieved2017-08-28.
  15. ^Corna, Nicola (2017-08-28)."me_cleaner: Tool for partial deblobbing of Intel ME/TXE firmware images".GitHub.Retrieved2017-08-28.
  16. ^Tanenbaum, Andrew S."An Open Letter to Intel".Archivedfrom the original on 2022-06-17.Retrieved2022-09-06.
  17. ^Tanenbaum, Andy(2006-09-25)."Introduction to MINIX 3".OSnew.OSnews.Retrieved2008-07-04.FromRebirthsection: "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. ForWindows 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. "
  18. ^"CSAIL Event Calendar".Csail.mit.edu. Archived fromthe originalon 2012-02-04.Retrieved2014-05-01.
  19. ^ab"Tanenbaum-Torvalds debate, Part II".Cs.vu.nl. 2006-05-12.Retrieved2014-05-01.
  20. ^"Reliability".MINIX3.org.Archived fromthe originalon July 1, 2006.
  21. ^"MinixReleases – Minix Wiki".Wiki.minix3.org.Retrieved2014-05-01.
  22. ^"Minix versions and their use in teaching".Archived fromthe originalon 2006-07-11.Retrieved2021-06-16.
  23. ^ab"LICENSE (3.1.0)".GitHub.Retrieved2021-06-16.
  24. ^ab"LICENSE (3.1.1)".Retrieved2021-06-16.
  25. ^ab"LICENSE (3.1.2)".GitHub.Retrieved2021-06-16.
  26. ^Swift, Björn Patrick."Individual Programming Assignment User Mode Scheduling in Minix 3"(PDF).Minix3.org.
  27. ^MINIX Release 3.3.0
  28. ^"Minix1: Copying and Use Policies".2007-02-13.Archivedfrom the original on 2020-06-14.
  29. ^"The MINIX 3 Operating System".minix3.org.Archived fromthe originalon 2012-01-13.
  30. ^"FAQ – Minix Wiki".Minix3.org. 2013-11-09.Retrieved2014-05-01.
  31. ^"Improvements since V2".minix3.org.Archived fromthe originalon April 17, 2006.
  32. ^"MINIX Releases".wiki.minix3.org.Archived fromthe originalon 21 June 2012.Retrieved29 February2012.
  33. ^"mascot [Wiki]".wiki.minix3.org.Retrieved2017-07-20.
  34. ^"Minix3".Archived from the original on 10 November 2017.Retrieved5 July2006.{{cite web}}:CS1 maint: bot: original URL status unknown (link)
  35. ^"Minix3".minix3.org.Retrieved2017-11-11.

Further reading[edit]

External links[edit]

Wikibooks has a book on the topic of:Minix 3
Retrieved from "https://en.wikipedia.org/w/index.php?title=Minix_3&oldid=1195379940"