Two years ago i was watching a video on youtube introducing the architecture of the MINIX 3 operating system, honestly it was really awesome and worth to be shared with you now.
In this post i will introduce to you the MINIX operating system architecture and design. I will give a small introduction about the design goals of minix then will push you into the details of all the modules and the hierarchy of the MINIX kernel modules.
Agenda
- Introduction
- Minix 3 Features
- Design Goals
- Minix 3 Architecture
- Minix 3 Drivers and Servers
- Reliability and security
- Conclusion
- References
MINIX 3 is a new open-source operating system designed to be highly reliable, flexible, and secure.
It is loosely based somewhat on previous versions of MINIX, but is fundamentally different in many key ways.
MINIX 1 and 2 were intended as teaching tools; MINIX 3
adds the new goal of being usable as a serious system on resource-limited and embedded computers
and for applications requiring high reliability
This new OS is extremely small, with the part that runs in kernel mode under 6000 lines of executable code. The parts that run in user mode are divided into small modules, well insulated from one another. For example, each device driver runs as a separate user-mode process so a bug in a driver (by far the biggest source of bugs in any operating system), cannot bring down the entire OS. In fact, most of the time when a driver crashes it is automatically replaced without requiring any user intervention, without requiring rebooting, and without affecting running programs. These features, the tiny amount of kernel code, and other aspects greatly enhance system reliability.
This new OS is extremely small, with the part that runs in kernel mode under 6000 lines of executable code. The parts that run in user mode are divided into small modules, well insulated from one another. For example, each device driver runs as a separate user-mode process so a bug in a driver (by far the biggest source of bugs in any operating system), cannot bring down the entire OS. In fact, most of the time when a driver crashes it is automatically replaced without requiring any user intervention, without requiring rebooting, and without affecting running programs. These features, the tiny amount of kernel code, and other aspects greatly enhance system reliability.
MINIX 3 Features
- POSIX compliant
- Networking with TCP/IP
- X Window System
- Languages: cc, gcc, g++, perl, python, etc.
- Over 650 UNIX programs
- Many improvements since V2
- Full multiuser and multiprogramming
- Device drivers run as user processes
- High degree of fault tolerance
- Full C source code supplied
Design Goals
The approach that MINIX 3 uses to achieve high reliability is fault
isolation. In particular, unlike traditional OSes, where all
the code is linked into a single huge binary running in kernel mode, in
MINIX 3, only a tiny bit of code runs in kernel mode--about 4000 lines in all (Minix 2).
This code handles interrupts, process scheduling, and interprocess
communication. The rest of the operating system runs as a collection of
user-mode processes, each one encapsulated by the MMU hardware and none of
them running as superuser. One of these processes, dubbed the
reincarnation server, keeps tabs on all the others and when one of
them begins acting sick or crashes, it automatically replaces it by a fresh
version. Since many bugs are transient, triggered by unusual timing, in most
cases, restarting the faulty component solves the problem and allows the
system to repair itself without a reboot and without the user even noticing it.
This property is called self healing, and traditional systems do not have it.
Minix 3 Architecture
The structure of MINIX 3 is shown in Fig. 1. It is constructed as a series of
layers. At the bottom, running in kernel mode, is a microkernel, consisting
of about 3000 lines of C and 800 lines of assembler (Minix 2). Above that comes a layer
of device drivers, with each driver in a separate user-mode process to ease
in replacing it should it fail. Then come the servers, which form the core
of the operating system. These include the reincarnation server mentioned
above, the file server, the process manager, and others, including the
X server, the data store, and various others. Finally, on top of that come
the user processes. Although internally, MINIX 3 is completely different
from other UNIX systems, it supports the standard POSIX interface to
applications, so normal UNIX software can be ported fairly easily.
Fig. 1
The components communicate by passing fixed-length messages. For example,
a user process requests file I/O send sending a message to the file server,
which then checks its cache and if the needed block is not present, sends a
message to the disk driver process to go get the block. While sending a
message adds a little bit of overhead (about 500 nsec on a 3-GHz Pentium 4),
the system is still quite responsive. For example, a complete system build,
which requires over 120 compilations, takes well under 10 sec.
Minix 3 Drivers and Servers
- Drivers and servers run as user mode processes
- Powers granted to them are carefully cotrolled
- Non can execute privileged instructions
- Time slicing so drivers/servers in infinite loop can't hang sys
- None can access kernel memory
- None can directly access other address spaces
- Bit map for determining allowed kernel calls
- Bit map for who each one can send to
- No direct I/O and list of allowed I/O ports via kernel
- User mode servers
- File server:
- File system interface to user space programs
- Process manager
- Process management (Creation-Termination)
- Handles signals
- Virtual memory server
- Mechanisms is in the kernel, policy is in the VM server
- Keeps track of free and used pages
- Catches and handles page faults
- Data store
- Small local name server
- Used to map server name to end point
- Could be used for recoverable drivers
- Information server
- Used for debug dumps
- Network server
- Contains full TCP/IP stack in user space (Interesting huh? :-D)
- X server
- Reincarnation server
- Parent of all drivers and servers
- Whenever a server/driver dies the RS collects it
- RS checks a table for action to take e.g., Restart it
- RS also ping drivers and servers frequently
Reliability and security
Kernel reliability and security
- Fewer line of codes means fewer kernel bugs
- No foreign code (e.g., drivers) in the kernel
- Static data structures (no malloc in kernel)
- Removing bugs to user space reduces their power
- Fixed length messages (no buffer overruns)
- Initial rendezvous system was simple
- No lost messages
- No buffer management
- Interrupts and messages are unified
- Problem:
- Clients send messages to server
- Server tries to respond, but client has died
- Server can't send message and thus hangs
- Solution:
- Asynchronous messages
- Untrusted code: heavily isolated
- Bugs, viruses cannot spread to other modules
- Cannot touch kernel data structures
- Bad pointers crash only one driver; recoverable
- Infinite loops detected and driver restarted
- Restricted power to do damage (not superuser)
- Current OSes are bloated and unreliable
- Minix 3 is an attempt at a reliable, secure OS
- Kernel is very small (6000 LoC)
- OS runs as a collection of user space processes
- Each driver is a separate process
- Each OS component has restricted privileges
- Faulty drivers can be replaced automatically
No comments:
Post a Comment