Embed Size (px)
Citation preview
Brno University of Technology
Faculty of Information Technology
System GNU/Hurd onArchitecture x86
Bachelor Project
2006 Zbynek Michl
System GNU/Hurd onArchitecture x86
Submitted in partial fulfillment of the requirements for the degree of Bachelor of InformationTechnology at Brno University of Technology, Faculty of Information Technology,April 27, 2006
c© Zbynek Michl, 2006
The author thereby grants persmission to reproduce and distribute copies of this documentin whole or in part to Brno University of Technology, Faculty of Information Technology.
Declaration
I hereby declare that I have created this project on my own and under the supervision ofIng. Tomas Kasparek. I have listed all information sources which I used.
. . . . . . . . . . . . . . . . . . . . . . .Zbynek Michl
April 27, 2006
Abstract
This project focuses on the GNU Hurd operating system. The first part presents conceptof the Hurd, Mach and L4 microkernels that create a base of the whole system. The secondpart describes a few installation procedures of the Hurd on x86 architecture. Current statusof the Hurd and presumption of the future development is also mentioned.
Keywords
Coyotos, Debian, GNU, GPL, Grub, Hurd, Hurd-NG, kernel, kernel space, L4, L4.Sec,Mach, microkernel, ngHurd, operating system, Pistachio, POSIX, server, translator, UNIX,user space.
Acknowledgements
First, I would like to thank my supervisor Ing. Tomas Kasparek for the opportunity towork on this project and for the time to discuss problems with him. My special thanks goto my family for the possibility to study in Brno and for their constant support all the timeas well as to my friends for their encouragement.
Abstrakt
Tato prace se zabyva operacnım systemem GNU Hurd. Prvnı cast prace je zamerena nakoncept Hurdu, dale na mikrojadra Mach a L4, ktera tvorı zaklad celeho systemu. Druhacast popisuje nekolik instalacnıch postupu Hurdu na architekture x86. Prace take sledujeaktualnı stav Hurdu a snazı se odhadnout dalsı budoucnost vyvoje.
Klıcova slova
Coyotos, Debian, GNU, GPL, Grub, Hurd, Hurd-NG, jadro, L4, L4.Sec, Mach, mikrojadro,ngHurd, operacnı system, Pistachio, POSIX, prostor jadra, server, translator, UNIX, uzi-vatelsky prostor.
Contents
Contents 6
1 Prologue 8
2 Monolithic Kernels and µ-kernels 102.1 What is a Kernel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Monolithic Kernel Based Systems . . . . . . . . . . . . . . . . . . . . 102.1.2 µ-kernel Based Systems . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 The GNU Hurd 133.1 The GNU Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 The Hurd’s Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 The Hurd’s Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 The Hurd’s History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 Servers and Translators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1 Translator Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5.2 Translator Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5.3 Passive and Active Translators . . . . . . . . . . . . . . . . . . . . . 163.5.4 Managing Translators . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.5 The GNU Hurd’s Translators and Servers . . . . . . . . . . . . . . . 18
3.6 Security Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.6.1 Authentication Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 193.6.2 POSIX Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . 203.6.3 Some Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 The Mach µ-kernel 214.1 About Mach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Mach Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 GNU Mach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4 Interprocess Communication (IPC) . . . . . . . . . . . . . . . . . . . . . . . 224.5 Memory Handling in GNU/Hurd with Mach . . . . . . . . . . . . . . . . . . 22
4.5.1 Paging with Mach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.5.2 Some Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6 Device Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6
5 The L4 µ-kernel 245.1 About L4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 Design Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3 Registers and Address Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3.1 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3.2 Address Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.4.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.4.2 Identifying Threads and Address Spaces . . . . . . . . . . . . . . . . 27
5.5 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.5.1 Communication Within an Address Space . . . . . . . . . . . . . . . 275.5.2 Communication Between Address Spaces . . . . . . . . . . . . . . . 28
5.6 Memory Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.7 Interprocess Communication (IPC) . . . . . . . . . . . . . . . . . . . . . . 30
5.7.1 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.7.2 Message Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.7.3 Acceptor and Buffer Registers . . . . . . . . . . . . . . . . . . . . . . 315.7.4 Send and Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6 GNU Mach and L4 Differences 326.1 GNU Mach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 L4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7 GNU/Hurd Installation 347.1 About Debian GNU/Hurd . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.2 Native Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.2.2 CDs Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.2.3 Base System Installation — Stage One . . . . . . . . . . . . . . . . . 357.2.4 Base System Installation — Stage Two . . . . . . . . . . . . . . . . 367.2.5 System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 377.2.6 Final Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.3 Cross Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.3.2 Install Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.3.3 Base System Installation . . . . . . . . . . . . . . . . . . . . . . . . . 417.3.4 Grub Boot Loader Setup . . . . . . . . . . . . . . . . . . . . . . . . 41
8 Current Status of the GNU/Hurd 428.1 Hurd µ-kernel Usage History . . . . . . . . . . . . . . . . . . . . . . . . . . 428.2 Known Flaws and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 448.3 Linux-related L4 Based Projects . . . . . . . . . . . . . . . . . . . . . . . . 45
9 Epilogue 46
7
Chapter 1
Prologue
The most important program that runs on a computer is an operating system (OS). Everygeneral-purpose computer have an operating system to run other programs. Operatingsystems perform basic tasks, such as recognizing input from the keyboard, sending outputto the display screen, keeping track of files and directories on the disk, and controllingperipheral devices such as disk drives and printers.
Operating systems provide a software platform on the top of which other programs,called application programs, can run. The application programs must be written to run onthe top of a particular operating system. Your choice of the operating system, therefore,determines a great extent of applications you can run.
The GNU Hurd is a set of servers (or daemons, in UNIX-speak) that work on the topof a microkernel (µ-kernel for short). Together, they form a base of the GNU operatingsystem. It has been under development since 1991 by the GNU Project and is distributedas free software under the GPL. The Hurd aims to surpass UNIX kernels in functionality,security and stability, while remaining largely compatible with them. This is done by havingthe Hurd track the POSIX specification, while avoiding arbitrary restrictions on the user.
Chapter 2 — describes monolithic kernel based systems and µ-kernel based systems. Es-pecially differences between mono-server and mutli-server systems are explained.
Chapter 3 — presents the GNU Hurd system. It covers its history, Hurd’s goals anddescription of active and passive translators in detail. Hurd’s security infrastructureis mentioned as well.
Chapter 4 — focuses on the Mach µ-kernel. The Mach key features, interprocess com-munication, memory handling, device drivers and others are mentioned there.
Chapter 5 — describes the L4 µ-kernel in detail. You can find table with various imple-mentations of the L4 there, sections about address spaces, threads, memory mappingand interprocess communication.
Chapter 6 — presents GNU Mach and L4 µ-kernel differences. Mainly interprocess com-munication, virtual memory management and device drivers differences are described.
Chapter 7 — focuses on Debian GNU/Hurd installation on the x86 architecture. Wedescribe native installation procedure (on computer without OS) and cross installation(on computer with Debian GNU/Linux installed).
8
Chapter 8 — describes current status of the GNU Hurd. There is shown Hurd’s µ-kernel usage history and Hurd’s releases overview. Next, you can find in this chaptersome flaws and limitations of current Hurd system. Some Linux-related projects arementioned as well.
9
Chapter 2
Monolithic Kernels and µ-kernels
2.1 What is a Kernel?
Since the operating system provides an hardware abstraction layer, and since it must provideresource sharing, every access to the hardware from user programs should be done throughthe operating system. To enforce this in a secure way, and prevent malicious or buggyapplications to mess up with the hardware, a protection is needed at the hardware level.
Hardware must provide at least two execution levels:
Kernel mode — In this mode, the software has access to all the instructions and everypiece of hardware.
User mode — In this mode, the software is restricted and cannot execute some instruc-tions, and is denied access to some hardware (like some area of the main memory, ordirect access to the IDE bus).
So, we define two spaces at software level:
Kernel space — Code running in the kernel mode is said to be inside the kernel space.
User space — Every other programs, running in user mode, is said to be in user space.
2.1.1 Monolithic Kernel Based Systems
This is the traditional design of UNIX systems. Every part which is to be accessed by mostprograms which cannot be put in a library is in the kernel space:
• Device drivers
• Scheduler
• Memory handling
• File systems
• Network stacks
Many system calls are provided to applications (more than 250 for Linux 2.4), to allowthem to access all those services.
This design has several flaws and limitations:
10
• Coding in kernel space is hard, since you cannot use common libraries (like a full-featured libc), debugging is harder (it is hard to use a source-level debugger like gdb),rebooting the computer is often needed, . . . Remember this is not just a problem ofconvenience to the developer: as debugging is harder, as difficulties are stronger, it islikely that code is “buggier”.
• Bugs in one part of the kernel have strong side effects, since every function in thekernel has all the privileges, a bug in one function can corrupt data structure ofanother, totally unrelated part of the kernel, or of any running program.
• Kernels often become very huge (more than 100 MB of source code for Linux 2.6),and difficult to maintain.
• The presence of strong side effects makes the whole kernel less modular (rememberthe VM issues of Linux 2.4, some people suggested to make the VM modular, allowingthe system administrator to choose one VM at compile time, but the impact of theVM over the other parts of the code was so huge that the idea was dropped). Andsince kernel code runs with all the privileges at hardware level, only the systemadministrator can be allowed to load a module inside the kernel space.
emacs
bashls
gccbash
User Space
Kernel
ext2VFS
TCP/IPVMM
IDE
Figure 2.1: Design of monolithic kernel based system
2.1.2 µ-kernel Based Systems
Principles
Only parts which really require to be in a privileged mode are in kernel space:
• IPC (Inter-Process Communication)
• Basic scheduler, or scheduling primitives
• Basic memory handling
• Basic I/O primitives
11
Many critical parts are now running in user space:
• The main part of scheduler
• Memory handling
• File systems
• Network stacks
Mono-server Systems
A single user-space program (server) handles everything that belonged to the kernel. Thetwo most common examples are MachOS and L4Linux (a port of Linux as a user-spaceserver on top of the L4 microkernel). This split allows better hardware independence ofthe operating system itself, a slightly easier development, and a limited improvement inoverall security (since the code running in the user-space, the server cannot directly accessthe hardware).
But this design still has most drawbacks of monolithic systems: if the monolithic servercrashes, the whole system crashes; it is impossible to add code to it without being root,changing most of the code requires a reboot, etc.
Multi-server Systems
All features are now split into a set of communicating processes, with each of them handlingonly a very specific task (like a TCP/IP server or an ext2fs server). This modularity allowsto replace components easily, an easier developement, a far better fault-tolerance (sincea crash of one of servers cannot corrupt the internal state of any other), and far moreflexibility for the end user.
But, like always in computer science, all those benefits come with several drawbacks:the communication between all servers can slow down the whole system, and the definitionof a strict set of interfaces and protocols for communication between those servers is anextra work to do.
emacs
bash
ls
gcc
bash
User Space
Kernel
ext2
VFS
TCP
/IP
VMM
Server
IPCIDE
VMM
(Base)
emacs
bashls
gccbash
User Space
Kernel
IPCIDE
VMM
(Base)ext2
TCP/IP
VMM
Figure 2.2: Schemes of mono-server and multi-server based system
12
Chapter 3
The GNU Hurd
3.1 The GNU Project
The GNU Project was started by Richard M. Stallman in 1983. The goal of the project isto create a full operating system and all applications required to allow any user to be ableto use only Free Software to perform whatever task he needs to use a computer for. GNUmeans GNU is Not Unix, since GNU takes many ideas from UNIX, but does not intend tobe “only” a Free implementation of UNIX, but to correct UNIX flaws and weaknesses atthe same time.
3.2 The Hurd’s Definition
The GNU Hurd is a set of servers, libraries and interfaces, running on top of a µ-kernel1,and providing the services which used to be inside the kernel.
3.2.1 Vocabulary
The Hurd — The Hurd, or the GNU Hurd, is the set of servers, it is not an operatingsystem, and since it runs in user space, it is not what we call a kernel. Hurd meansHird of Unix-Replacing Daemons and Hird means Hurd of Interfaces RepresentingDepth, but all of them are spelled like the word herd, which is the real meaning ofthis name: the GNU Hurd is a herd of gnus.
GNU/Hurd — GNU/Hurd, or GNU, is the full operating system, including the µ-kernel,the Hurd, the dynamic linker (GNU ld), the C library (GNU libc) and other applica-tions.
3.3 The Hurd’s Goals
The Hurd is core of the GNU project. Every program running on the GNU system relyupon the Hurd to perform most of operating system related tasks. The philosophy of theGNU project, as defined in the GNU manifesto, was the philosophy leading to the Hurddesign. The goal of the GNU project is to give back the freedom to the users of computer
1Hurd has been originally developed on the top of GNU Mach, currently there is an effort to replaceMach with another µ-kernel (see section 8.1).
13
Figure 3.1: The GNU Hurd’s logo
systems; but not only at the license level. Every technical limitation which is not strictlynecessary is a reduction of user freedom. The fact that non-privilegied user in a UNIXsystem cannot mount an ISO image (setuid does not count), or test his own file systemimplementation, is a reduction of user freedom. With its highly modular design, the Hurdgives back some additional freedom to the users. This is a major idea of the whole GNUproject, displayed even in the name of the project: we want to stay compatible with UNIXprograms as much as possible, but we want to overthrow as much limitations as we can.
Interfaces between components of the GNU Hurd were clearly defined and fixed as soonas possible during the development. Fixed interfaces are very important to allow users todesign their own replacement of some part of the system, without breaking the other parts.It also suppress compatibility problems.
Interfaces of the GNU Hurd were designed to fill the flaws of UNIX systems. Forexample, there is no (standard) way in a UNIX system to create a file with no name. Thecommonly used method is to create it in /tmp, and then unlink it without closing the filedescriptor. The kernel will wait for the file descriptor to be closed before deleting it. Butduring a short amount of time, the file has a name, and this causes many security holes.Another example is notification: the most common way to ask the kernel of UNIX systemto be informed when a file is changed (SIGIO) is non-portable, and not very flexible (inrecent UNIX kernels, other ways can exist, but still lack flexibility).
3.4 The Hurd’s History
1983 Richard Stallman starts the GNU project1988 Mach 3 is chosen as µ-kernel1991 Mach 3 is released under a Free license1991 Thomas Bushnell, BSG, founds the Hurd1994 GNU/Hurd boots for the first time1997 The Hurd version 0.2 is released1998 Marcus Brinkmann creates Debian GNU/Hurd2002 GNU Mach version 1.3 is released2002 Debian GNU/Hurd has 4 CDs2002 Port of the Hurd to L4 is started2002 POSIX threads are now supported2003 L4Ka::Pistachio 0.1 is released2003 Ext2fs without the 2GB limit in alpha stage2004 Ext2fs without the 2gb limit reach release candidate2005 Ext2fs without the 2gb in Debian GNU/Hurd2005 First program running on L4Hurd2005 Initial Gnome port2005 Debian GNU/Hurd K10 series is released
14
3.5 Servers and Translators
3.5.1 Translator Concept
Before we take a closer look at translators, let us consider regular filesystems. A filesystemis a store for a hierarchical tree of directories and files. You access directories and files bya special character string, the path. Furthermore, there are symbolic links to refer to onefile at several places in the tree, there are hard links to give one and the same file severalnames. There are also special device files for communication with the hardware devicedrivers of the kernel, and there are mount points to include other stores in the directorytree. Then there are obscure objects like FIFOs.
Although these objects are very different, they share some common properties, forexample, they have all an owner and a group associated with them as well as access rights(permissions). This information is written in inodes. This is actually a further commonality:Every object has exactly one inode associated with it (hard links are somewhat special asthey share one and the same inode). Sometimes, the inode has further information storedin it. For example, the inode can contain the target of a symbolic link.
However, these commonalities are usually not exploited in the implementations, despitethe common programming interface to them. All inodes can be accessed through thestandard POSIX calls, for example read() and write(). For example, to add a new objecttype (for example a new link type) to a common monolithic UNIX kernel, you would needto modify the code for each filesystem separately.
In the Hurd, things work differently. Although in the Hurd a special filesystem servercan exploit special properties of standard object types like links (in the ext2 filesystem withfast links, for example), it has a general interface to add such features without modifyingexisting code.
The trick is to allow a program to be inserted between the actual content of a file and theuser accessing this file. Such a program is called a translator, because it is able to processthe incoming requests in many different ways. In other words, a translator is a Hurd serverwhich provides the basic filesystem interface.
Translators have very interesting properties. From the kernel’s point of view, they arejust another user process. This means, translators can be run by any user. You don’t needroot privileges to install or modify a translator, you only need the access rights for theunderlying inode the translator is attached to. Many translators don’t require an actual fileto operate, they can provide information by their own means. This is why the informationabout translators is stored in the inode.
Translators are responsible to serve all file system operations that involve the inodethey are attached to. Because they are not restricted to the usual set of objects (devicefile, link etc), they are free to return anything that makes sense to the programmer. Onecould imagine a translator that behaves like a directory when accessed by cd or ls and atthe same time behaves like a file when accessed by cat.
3.5.2 Translator Examples
Mount Points
A mount point can be seen as an inode that has a special translator attached to it. Its pur-pose would be to translate filesystem operations on the mount point in filesystem operationson another store, let’s say, another partition.
15
Indeed, this is how filesystems are implemented under the Hurd. A filesystem is a trans-lator. This translator takes a store as its argument, and is able to serve all filesystemoperations transparently.
Device Files
There are many different device files, and in systems with a monolithical kernel, they areall provided by the kernel itself. In the Hurd, all device files are provided by translators.One translator can provide support for many similar device files, for example all hard diskpartitions. This way, the number of actual translators needed is quite small. However, notethat for each device file accessed, a separate translator task is started. Because the Hurdis heavily multi threaded, this is very cheap.
When hardware is involved, a translator usually starts to communicate with the kernelto get the data from the hardware. However, if no hardware access is necessary, the kerneldoes not need to be involved. For example, /dev/zero does not require hardware access,and can therefore be implemented completely in user space.
Symbolic Links
A symbolic link can be seen as a translator. Accessing the symbolic link would start upthe translator, which would forward the request to the filesystem that contains the file thelink points to.
However, for better performance, filesystems that have native support for symbolic linkscan take advantage of this feature and implement symbolic links differently. Internally,accessing a symbolic link would not start a new translator process. However, to the user,it would still look as if a passive translator is involved (see below for an explanation whata passive translator is).
Because the Hurd ships with a symlink translator, any filesystem server that providessupport for translators automatically has support for symlinks (and firmlinks, and devicefiles etc)! This means, you can get a working filesystem very fast, and add native supportfor symlinks and other features later.
3.5.3 Passive and Active Translators
There are two types of translators, passive and active. They are really completely differentthings, so don’t mix them up, but they have a close relation to each other.
Active Translators
An active translator is a running translator process, as introduced above. You can set andremove active translators using the settrans -a command. The -a option is necessary totell settrans that you want to modify the active translator.
The settrans command takes three kind of arguments. First, you can set options forthe settrans command itself, like -a to modify the active translator. Then you set theinode you want to modify. Remember that a translator is always associated with an inodein the directory hierarchy. You can only modify one inode at a time. If you do not specifyany more arguments, settrans will try to remove an existing translator. How hard it triesdepends on the force options you specify (if the translator is in use by any process, you willget “device or resource busy” error message unless you force it to go away).
16
But if you specify further arguments, it will be interpreted as a command line to runthe translator. This means, the next argument is the filename of the translator executable.Further arguments are options to the translator, and not to the settrans command.
For example, to mount an ext2fs partition, you can run settrans -a -c /mnt /hurd/-ext2fs /dev/hd2s5. The -c option will create the mount point for you if it doesn’t existalready. This does not need to be a directory, by the way. To unmount, you would trysettrans -a /mnt.
Passive Translators
A passive translator is set and modified with the same syntax as the active translator (justleave away the -a), so everything said above is true for passive translators, too. However,there is a difference: passive translators are not yet started.
This makes sense, because this is what you usually want. You don’t want the partitionmounted unless you really access files on this partition. You don’t want to bring up thenetwork unless there is some traffic and so on.
Instead, the first time the passive translator is accessed, it is automatically read out ofthe inode and an active translator is started on top of it using the command line that wasstored in the inode. This is similar to the Linux automounter functionality. However, itdoes not come as an additional bonus that you have to set up manually, but an integralpart of the system. So, setting passive translators defers starting the translator task untilyou really need it. By the way, if the active translator dies for some reason, the next timethe inode is accessed the translator is restarted.
There is a further difference: active translators can die or get lost. As soon as the activetranslator process is killed (for example, because you reboot the machine) it is lost forever.Passive translators are not transient and stay in the inode during reboots until you modifythem with the settrans program or delete the inodes they are attached to. This means,you don’t need to maintain a configuration file with your mount points.
One last point: Even if you have set a passive translator, you can still set a differentactive translator. Only if the translator is automatically started because there was no activetranslator the time the inode was accessed the passive translator is considered.
3.5.4 Managing Translators
As mentioned above, you can use settrans to set and alter passive and active translators.There are a lot of options to change the behaviour of settrans in case something goeswrong, and to conditionalize its action. Here are some common usages:
• settrans -c /mnt /hurd/ext2fs /dev/hd2s5 mounts a partition, the translatorwill stay across reboots.
• settrans -a /mnt /hurd/ext2fs ~/dummy.fs mounts a filesystem inside a datafile, the translator will go away if it dies.
• settrans -fg /nfs-data forces a translator to go away.
You can use the showtrans command to see if a translator is attached to an inode. Thiswill only show you the passive translator though.
You can change the options of an active (filesystem) translator with fsysopts withoutactually restarting it. This is very convenient. For example, you can do what is called
17
“remounting a partition read-only” under Linux simply by running fsysopts /mntpoint--readonly. The running active translator will change its behaviour according to yourrequest if possible. fsysopts /mntpoint without a parameter shows you the current set-tings.
3.5.5 The GNU Hurd’s Translators and Servers
auth — The authentication server which passes credentials when two mutually untrustingservers communicate. In a sense, each auth server establishes a domain of trust.
console — A translator that provides virtual consoles.
crash — The server gets active whenever a task gets a fatal error signal, for examplebecause it violates memory boundaries (segmentation fault). The crash server hasthree modes of operation: suspending the process group (pgrp) of the offending task,killing it or dumping a core file.
exec — The execute server that manages the creation of a new process image from theimage file.
ext2fs — A server that manages ext2-type filesystems. It does the same as ext2fs.static,only that ext2fs.static is a statically linked executable.
fakeroot — A translator for faking privileged access to an underlying filesystem.
fatfs — A translator that manages FAT-type filesystems.
fifo — A translator that implements named pipes.
firmlink — The firmlink translator is sort of halfway between a symbolic link and a hardlink.
ftpfs — A translator for FTP filesystems.
fwd — When accessed, the fwd translator forwards requests to another translator. It isused in the fifo and symlink translators. The idea is so that you don’t get a jillionservers for such trivial things; fwd is used to coordinate having one server handleseveral different nodes conveniently.
hello — A translator providing a warm greeting. hello-mt is the same, but multi-threaded.
hostmux — A translator for invoking host-specific translators.
ifsock — A server which only handles S_IFSOCK filesystem nodes for filesystems whichdon’t do it themselves, acting as a hook upon which to hang UNIX domain socketaddresses. pfinet and pflocal implement the socket API.
init — The initialisation server for system boot procedures and basic runtime configura-tions.
iso9660fs — A server for iso9660-type filesystems, commonly used on compact disks.Server does the same as iso9660fs.static, only that iso9660fs.static is a staticallylinked executable.
18
mach-defpager – A standalone version of the Mach default pager.
magic — A translator that returns the magic retry result MAGIC. Normal end users proba-bly need not to know much about it since it is used, for example, to facilitate terminalI/O.
new-fifo — Alternative translator for named pipes.
nfs — A translator that supports Sun’s Network File System.
null — The kitchen sink. A server for lots of free space and countless numbers of zeroes,implements /dev/null and /dev/zero.
password — The Hurd standard password server.
pfinet — A server for TCP/IP, which implements the (IPv4) PF_INET protocol family.
pflocal — This server implements UNIX domain sockets. Needed for pipes, for example.
proc — The process server that assigns PID’s and process structures to tasks, and managesall the process level stuff like wait, bits of fork, C library support.
proxy-defpager — This translator allows access to control interfaces of Mach defaultpager.
storeio — The storage translator for devices and other stores.
streamio — A translator for stream devices.
symlink — A translator for symbolic links for filesystems which don’t support it them-selves.
term — The terminal translator that implements a POSIX terminal.
tmpfs — A translator which provides tmp filesystem.
ufs — A server for ufs-type filesystems. It does the same as ufs.static, only that ufs.staticis a statically linked executable.
usermux — A translator for invoking user-specific translators.
3.6 Security Infrastructure
3.6.1 Authentication Tokens
The security on GNU/Hurd is based on authentication tokens. A token is the right foran application to perform a specific set of tasks. Tokens are handled by the auth server,a server trusted by all other pograms, and enforcing that no one lies on which token theyhave. Through auth, tokens can be given, destroyed, or created. Tokens can exist foranything, for example you can imagine a token “is able to bind ports below 1024”.
Tokens are comparable to Kerberos tickets, or POSIX capatibilities.
19
3.6.2 POSIX Compatibility
POSIX compatibility, with regard to authentication, is implemented via specific tokens:UIDs and GIDs are only a kind of tokens that auth can deliver. It is therefore possible foran application to have several UIDs tokens, and as such being able to act with differentPOSIX identities at the same time. Programs can lose or give UIDs at any time duringtheir execution — they just need to contact auth, and the password server (or any otherauth-trusted server that can manage authentication, for example a server that matchesa user-given and a sysadmin-provided certificates).
A specific addauth command (a normal, non-suided program) can give tokens to pro-grams. If you are running a shell as kilobug, you can give the UID kilobug security tokento any currently running application with addauth -u kilobug -p [PID]. The same way,programs can drop their tokens, lowering their permissions.
Suid-ed Binaries
The translator in charge of a filesystem is the one enforcing the suid-bit. If you run/bin/ping as a normal user, the ext2fs translator managing the / filesystem will givethe root security token to the ping program, before starting it. Since a translator cannotgive a security token it doesn’t have, a translator ran by a normal user would not be ableto enfore the suid-bit, and this way there is no security risk in allowing normal users to runtranslators.
3.6.3 Some Applications
The Password Server
The password server is a very simple (around 200 code lines) program, which can give UIDand GID security tokens in exchange of a login/password pair. A ftp server, or an sshserver, could then run without any permission, and gives the user-provided login/passwordto the password server, in order to gain privileges and be able to answer to the user. Thehuge difference with UNIX systems is that the ftp or ssh server never has root privileges(or only at bind-time, and then drop it completly), and never has even the privileges ofa normal user before someone gives it a valid login/password pair. A flaw inside ftp or sshwould only give a shell with very few rights.
No Auth Programs
Programs can discard all the security tokens they have and become noauth programs. Thiscan be used to process untrusted contents, like a ghostscript interpreter running on contentscoming from an untrusted source. A security flaw inside the interpreter could not allowa malicious postscript file to damage your own files, since the interpreter discarded the UIDsecurity token before processing the data.
20
Chapter 4
The Mach µ-kernel
4.1 About Mach
Mach was one of the first µ-kernels. It was a project of Carnegie-Mellon university toimplement a fairly new theory. It came with a lot of new concepts:
• A complex and powerful IPC layer,
• It was designed for multiprocessor and even clusters,
• It use external pagers,
• It was the first system to clearly define the notions of task, thread
Mach was the first µ-kernel to be successful, taken and improved by OSF/1 and otherresearch groups. It was the base of MachOS, a mono-server operating system (with the UXserver running on top of the Mach µ-kernel and providing BSD compatibility).
4.2 Mach Key Features
Mach does quite a lot of things for a µ-kernel:
• It handles tasks as containers (a task contains memory areas, threads, IPC rights),
• A complex IPC system,
• The virtual memory layer, with an LRU decision algorithm,
• A basic scheduler,
• Device drivers.
4.3 GNU Mach
GNU Mach was derived from OSF Mach. The last stable version is 1.3, and maybe it isthe last of the 1.x branch. The new 2.0 version, might be released sometime in the future,uses the OSKit framework for device drivers (allowing nearly all drivers from Linux 2.2 tobe ported easily).
21
4.4 Interprocess Communication (IPC)
IPC with Mach is based on ports. A port is kernel managed entity which can be seen asa message queue, with one task having a receive right on the port, and any number of taskshaving send rights to the port. The task having the receive right can read the messagessent by the tasks having send rights. Receive rights can be given to another task, andsend rights can be given, destroyed or duplicated (rights are sent across tasks using IPCs).There is also a special send once right, which can be used only once, and is often used whenwaiting for an answer.
Communication across ports is asynchronous: a sending thread is not blocked until thereceiving task received the message. This implies that all IPC messages must be copied(either logically or physically) inside the kernel and queued there, which slows down theIPC a lot.
4.5 Memory Handling in GNU/Hurd with Mach
4.5.1 Paging with Mach
Mach takes the decision of which page to keep and which page to discard (move to back-endstorage) in time of memory pressure, using a Least Recently Used algorithm (LRU); butthe pagers are in user-space. When a page has to be evicted from memory, Mach sendsan IPC to the user-space pager associated with the page; it is up to the pager to save itsomewhere. When a page fault occurs, Mach asks to the pager to bring back the page tomemory, and then resumes the faulting application.
4.5.2 Some Applications
User space pagers can be used to implement different kind of backing stores: hard disks,compressed memory, a remote computer through networking, . . . Several pagers can handledifferent parts of the address space of the same task.
The Use in diskfs
The library used by regular filesystem translators (like ext2fs, iso9660fs, fatfs, . . . ) worksby mapping in memory all the metadata, and then using only pointer indirection to accessto the metadata. The GNU Mach VM handles all the caching, and a user-space pager isused to load and write pages to/from the backing store.
The problem is that, for filesystems with metadata spread all over the partition (likeext2fs), the whole partition has to be mapped into memory. That is why many diskfstranslators are limited to 2GB partitions on IA-32 (and that’s why fatfs isn’t limited to2 GB — the FAT is located at the beginning of the partition, so the only limitation is tohave the FAT be less than 2 GB).
Two possible solutions for this problem are either to set-up a tree of intelligent special-ized pagers, or to use a cache of mappings, creating and destroying mappings of meta-dataas needed. The current implementation of ext2fs in Debian GNU/Hurd (see section 7.1)contains a patch from Ognyan to cover this problem. It implements a caching of mappings,with static mapping of fixed metadata (since in ext2, some metadata are in fixed places,and others can be anywhere in the filesystem).
22
4.6 Device Drivers
The Mach kernel provides all low-level device support. Each device is represented as a portto which messages can be sent to transfer data or control the device. Data is transferredthrough read and write operations; the request and reply messages are exported separately,allowing both synchronous and asynchronous styles of I/O. The external memory objectprotocol allows a user to map the frame buffer for a graphics device directly into its addressspace.
23
Chapter 5
The L4 µ-kernel
5.1 About L4
Originally, L4 is the name of a second-generation µ-kernel designed and implemented around1995 by Jochen Liedtke, running on i486 and Pentium CPUs.
However, there are numerous implementations of the L4 API on several hardware ar-chitectures. You can see overview of various implementations in table 5.1 (the last one isLiedtke’s original implementation).
Note that this chapter is focused on the L4Ka::Pistachio implementation, which GNUHurd uses.
Name CPU Impl. Lng.L4Ka::Pistachio Pentium or better, IA64, PowerPC, Alpha,
64-bit MIPSC++
NICTA::L4-embedded ARM, x86 and MIPS C++Fiasco i486 or better, StrongARM, Linux (user-
mode L4 emulation)C++
P4 x86, MIPS, PowerPC, ARM CL4 for PowerPC PowerPC 603e CL4Ka::Hazelnut Pentium or better, StrongARM C++L4/MIPS MIPS R4x00 CL4/Alpha Alpha AXP 21264 AssemblerL4/x86 i486 or better Assembler
Table 5.1: Various implementations of the L4 µ-kernel
5.2 Design Philosophy
The most fundamental task of an operating system is to provide secure sharing of resources.A µ-kernel should to be as small as possible. Hence, the main design criterion of the µ-kernel is minimality with respect to security: A service (feature) is to be included in theµ-kernel if and only if it impossible to provide that service outside the kernel without lossof security. The idea is that once we make things small (and do it well), performance willlook after itself.
24
A strict application of this rule has some surprising consequences. Take, for example,device drivers. Some device drivers access physical memory (e.g. DMA) and can thereforebreak security. They need to be trusted. This does not, however, mean that they need tobe in the kernel. If they do not need to execute privileged instructions and if the kernel canprovide sufficient protection to run them at user level, then this is what should be done.Consequently, this is what L4 does.
According to Liedtke, and based on such reasoning, a µ-kernel must provide:
Address spaces — the basis of protection,
Threads — an abstraction of program execution,
Interprocess communication (IPC) — a mechanism to transfer data between addressspaces,
Unique identifiers (UIDs) — providing context-free addressing in IPC operations.
All these concepts will be explain in this chapter later.
5.3 Registers and Address Spaces
5.3.1 Registers
L4 µ-kernel provides programs with access to virtual registers. Virtual registers offer a fastinterface to exchange data between the µ-kernel and user threads. They are registers inthe sense that they are static per-thread objects. Depending on the specific processor type,they can be mapped to hardware registers or to memory locations. Mixed mappings, wheresome virtual registers map to hardware registers while others map to memory, are alsopossible.
There are three classes of virtual registers: Thread Control Registers (TCRs), MessageRegisters (MRs) and Buffer Registers (BRs).
In general, virtual registers can only be addressed directly, not indirectly through point-ers. The L4 API provides specific functions for accessing the three different classes of regis-ters. Loading illegal values into virtual registers, overwriting read-only virtual registers, oraccessing virtual registers of other threads in the same address space (which may be phys-ically possible if some are mapped to memory locations) is illegal and can have undefinedeffects on all threads of the current address space.
5.3.2 Address Space
An address space contains all the data that is directly accessible by a thread. It consists ofa set of mappings from virtual to physical memory. This set of mappings is partial in thesense that many mappings may be undefined, making the corresponding virtual memoryinaccessible. Figure 5.1 shows an example of how the virtual memory in an address spacemay map onto physical memory. The regions of virtual memory that are not mapped areinaccessible to threads running in that address space.
Typically an address space will contain a number of standard regions. These include thetext, data, heap, and stack regions. The text region contains program code, the data regioncontains preinitialised data used by the program, the heap region is used for dynamicallyallocated data, and the stack region is used for storing temporary data during execution.
25
Address Space
Physical Memory
Mapped Memory Unmapped Memory
Mapping
Figure 5.1: Mapping of virtual memory to physical memory
The text and data regions usually have a fixed size and do not change during execution ofa program. The heap and stack regions, on the other hand, can grow or shrink while theprogram is executing. Note that by convention on most architectures the heap grows uptoward high memory, while the stack grows down toward lower memory.
Figure 5.2 shows a typical arrangement of these regions in an address space. Note thatL4 does not enforce any specific layout of address spaces. The layout is generally determinedby a combination of the compiler and higher-level operating system services built on top ofL4.
Address Space
Text Data Heap Stack
0x0 0xfffff
Figure 5.2: A typical address space layout
5.4 Threads
A thread is the basic execution abstraction in L4. L4 threads are light-weight and cheapto manage. The light-weight thread concept together with fast IPC are the keys to theefficiency of L4 and OS personalities running on top of L4.
A thread is always associated with a specific address space. The relationship betweenthreads and address spaces is 1 : n, that is, a thread is associated with exactly one addressspace, while any address space can have many threads associated with it.
Each thread has its own set of virtual registers called the thread control registers (TCRs).These virtual registers are static (they keep their values until explicitly modified) and storethe thread’s private state (e.g., parameters for IPCs, scheduling information, the thread’sidentifiers, etc.). They are stored in an area of the address space called the thread controlblock (TCB). The TCB is actually split into two parts, there is the user TCB (UTCB),which is accessible by the thread, and the kernel TCB (KTCB) which is accessible only bythe kernel.
Each thread is further associated with a page-fault handler and an exception handler.These are separate threads that are set up to handle page faults and other exceptions causedby the thread.
Each thread in an address space has its own stack. A thread’s stack address is explicitlyspecified during thread creation. It is up to the thread to determine where to place its heap
26
— this is a design issue, but typically several threads in the same address space will sharea heap.
L4 also distinguishes between privileged and non-privileged threads. Any thread be-longing to the same address space as one of the initial threads created by the kernel uponboot-time is treated as privileged. Some system calls can only be executed by privilegedthreads.
Threads can be created as active or inactive threads. Inactive threads do not executebut can be activated by active threads that execute in the same address space. Theyare typically used during the creation of address spaces. A thread created active startsexecuting immediately after it is created. The first thing it does is execute a short receiveoperation waiting for a message from its pager. This message will provide the thread withan instruction and stack pointer and allow it to start executing its code.
5.4.1 Tasks
A task is the set of of threads sharing an address space. The terms task and address spaceare often used interchangeably, although strictly speaking they are not the same. We willtry to avoid using the term task where possible, prefering to specifically refer to an addressspace or thread.
5.4.2 Identifying Threads and Address Spaces
A thread is identified by its unique identifier (UID). A thread can actually have two identi-fiers, a local identifier and a global identifier. While a global identifer is valid in any addressspace, a local identifier is only valid within the thread’s address space. That is, a globalidentifier can be used by any thread, while a local identifier can only be used by threadsthat are part of the same task. In different address spaces, the same local thread ID mayidentify different and unrelated threads.
Unlike threads, address spaces do not have identifiers. Instead, an address space isidentified by the UID of any thread associated with that address space. This means thatan address space must always have at least one thread associated with it. That thread doesnot, however, have to be active.
5.5 Communication
One of the main activities that threads engage in is to communicate with other threads(for example, in order to request services from each other, in order to share results ofcomputations, etc.). There are two ways that threads communicate: using shared memory(see section 5.6), or using L4’s Interprocess Communication (IPC) facilities (see section5.7).
5.5.1 Communication Within an Address Space
When communicating with threads in the same address space, it is easiest (and most ef-ficient) to use shared memory. Threads in the same address space automatically sharememory, so they do not have to make use of L4’s memory mapping facilities. As long asboth threads agree on which shared memory region (or variables) to use, they are free tocommunicate in this way.
27
When threads communicate using shared memory it is necessary to avoid race condi-tions. This is best done by enforcing mutual exclusive access to shared memory. Note thatL4 does not provide any mutual exclusion primitives (such as semaphores) to do this, it isexpected that these are provided at user level (possibly using mechanisms provided by theunderlying hardware). Various implementations of user level mutual exclusion primitivesare available.
It is possible for threads in the same address space to communicate using IPC. Themain use for this is thread synchronisation. Addressing a thread in the same address spacecan be done using local or global thread Ids.
5.5.2 Communication Between Address Spaces
When communicating between address spaces (i.e., when threads in different address spacescommunicate with each other) both the use of shared memory and IPC are valid approaches.IPC is generally used for smaller messages and synchronisation, while shared memory isused to exchange larger amounts of data.
Communicating between address spaces using shared memory requires that all (commu-nicating) threads have access to the same memory region. This is achieved by having onethread map a region of its address space into the address spaces of the other threads. Theconcept of mapping memory is explained in section 5.6. Once a shared region of memoryhas been established, the threads communicate by simply reading from or writing to theparticular memory region. Note that, as mentioned previously, when communicating usingshared memory it is necessary to avoid race conditions.
Communication using IPC requires that the threads send messages to one another.A message is sent from a sender thread and addressed to a particular receiver thread.Messages can be used to directly share data (by sending it back and forth), to indirectlyshare data (by sending memory mappings), or as a control mechanism (e.g., to synchronise).
5.6 Memory Mapping
Address spaces can be recursively constructed. A thread can map parts of its address spaceinto another thread’s address space and thereby share data. Figure 5.3 shows an example oftwo address spaces with a region of address space A mapped into address space B. Both thethread running in address space A and the thread running in address space B can accessthe shared region of memory. Note, however, that the memory may have different virtualaddresses in the different address spaces. Thus, in the example, a thread running in addressspace A accesses the shared memory region using virtual address 0x1000000 while a threadin address space B uses virtual address 0x2001000.
A mapper (that is, the thread making the memory available) retains full control of themapped region of memory. In particular, the mapper is free to revoke a mapping at anytime. Revoking a mapping is called unmapping. After a mapping has been revoked, thereceiver of that mapping (the mappee) can no longer access the mapped memory. This isshown in figure 5.4. Here a thread in address space B can no longer access the region ofvirtual memory that used to contain the mapped memory.
Access to mapped memory is limited by the access permissions set by the mapper. Theseaccess permissions specify read permission, write permission, and execute permission anddetermine how the mappee can access the mapped memory. Note that a mapper cannotgrant access rights that it does not itself have. Thus, if a thread does not have write access
28
Address Space B
0x2001000
Address Space A
Physical Memory
0x1000000
Figure 5.3: Two address spaces sharing a region of memory
Address Space B
Address Space A
Physical Memory
Figure 5.4: A shared region of memory is unmapped
to a particular region of memory, it cannot map that memory with write permission intoanother address space.
It is also possible for a region of one address space to be granted to another addressspace. Granting differs from mapping in that after the grant has succeeded, the granterloses access to that region of its address space (i.e., it no longer has a valid mapping for thatregion). Figure 5.5 shows an example of the situation before and after a region of addressspace A has been granted to address space B. Unlike revocation of mappings, a grantercannot revoke a grant, as it no longer has access to the page.
Address Space B
Before Grant After Grant
Address Space A
Physical Memory
Address Space B
Address Space A
Physical Memory
Figure 5.5: A region of one address space is granted to another
Note that, for security reasons, when mapping or granting memory the receiver mustalways explicitly agree to accept maps or grants.
Mapping and granting of memory are implemented using L4’s IPC mechanism. In orderto map memory, a mapper sends the intended mappee a message containing a map itemspecifying the region of memory to be mapped. The mappee must explicitly specify that it
29
is willing to receive mappings. It also specifies where, in its own address space, the memoryshould be mapped. The receiver does not actually have to do anything with the receivedmap item (or grant item). The mapping is performed as a side effect of the IPC.
Note that although mappings apply to an address space, map messages are sent via IPCto a thread in that address space.
5.7 Interprocess Communication (IPC)
Message passing is the basic interprocess communication (IPC) mechanism in L4. It allowsL4 threads in separate address spaces to communicate by sending messages to each other.This message-passing IPC is the heart of L4. It is used to pass data between threads (eitherby value, with the µ-kernel copying the data between two address spaces, or by reference,through mapping or granting). L4 IPC is blocking, so it is used for synchronisation (eachsuccessful IPC operation results in a rendez-vouz ) and wakeup-calls (timeouts can be spec-ified, so IPC can be used for timed sleeps). It is even used for memory management (theµ-kernel converts a page fault into an IPC to a user-level pager), exception handling (theµ-kernel converts an exception fault into an IPC to a user-level exception handler), andinterrupt handling (the µ-kernel converts an interrupt into an IPC from a pseudo-threadto a user-level interrupt-handler).
5.7.1 Messages
A message consists of one mandatory and two optional sections. The mandatory messagetag is followed by the optional untyped-words section which is followed by the optionaltyped-items section. The message tag contains message control information and a messagelabel. The message control information specifies the size of the message and the kind ofdata contained in it. The µ-kernel associates no semantics with the message label; it allowsthreads to identify a message and is often used to encode a request key or to identify thefunction to be invoked upon reception of the message.
The untyped-words section holds arbitrary data that is untyped from the µ-kernel’spoint of view. The data is simply copied to the receiver. The µ-kernel associates nosemantics with it. The typed-items section contains typed data such as string items, mapitems, and grant items. Map items and grant items were introduced earlier and are usedto map and grant memory. String items are used for passing string data by reference.
5.7.2 Message Registers
IPC messages are transferred using message registers (MRs). A sender writes a messageinto the message registers associated with its own thread and a receiver reads the messageout of the message registers associated with its thread. Each thread has 64 MRs, numberedMR0 to MR63 (inclusive). A message can use some or all MRs to transfer untyped wordsand typed items. The message tag is always transfered in MR0.
MRs are transient read-once virtual registers. Once an MR has been read, its value isundefined until the MR is written again. The send phase of an IPC implicitly reads allMRs; the receive phase writes the received message into MRs.
MRs can be implemented as either special purpose (hardware) registers, general mem-ory locations, or general purpose (hardware) registers. It is generally up to the particularL4 implementation (and the hardware that it is implemented on) whether any MRs are
30
implemented as hardware registers and if so which ones. For example, in the MIPS imple-mentation MR0 to MR9 are implemented as hardware registers.
5.7.3 Acceptor and Buffer Registers
In order to be able to handle a received message, the receiver must explicitly agree to acceptmessages of that type. The acceptor is used to specify which typed items will be acceptedwhen a message is received. If an acceptor specifies that map or grant items are accepted,then it also specifies where the associated memory will be mapped in the receiver’s addressspace. If an acceptor specifies that string items are accepted, then any string items receivedare placed in the buffer registers (BRs).
BRs are registers in the sense that they are per-thread objects and can only be addresseddirectly, not indirectly through pointers. BRs are static objects like TCRs, i.e., they keeptheir values until explicitly modified. BRs can be mapped to either special registers or tomemory locations. There are 34 BRs numbered from BR0 to BR33 (inclusive).
The acceptor is always placed in BR0. Any string items received are placed in the BRsstarting at BR1.
5.7.4 Send and Receive
Messages are sent and received through the IPC system call. IPC is the fundamentaloperation for inter-process communication and synchronization. It can be used for intra-and inter-address-space communication. All communication is synchronous and unbuffered:a message is transferred from the sender to the recipient if and only if the recipient hasinvoked a corresponding IPC operation. The sender blocks until this happens or untila period specified by the sender has elapsed without the destination becoming ready toreceive. Similarly, the reciever blocks until a message has been recieved. The receivermust also supply all necessary buffers, as the kernel does not provide any such storage.This unbuffered operation reduces the amount of copying involved and is the key to high-performance IPC.
A single IPC call combines an optional send phase and an optional receive phase. Whichphases are included is determined by specific parameters to the IPC call. It is also possibleto specify timeouts for IPCs. Different combinations of timeouts and send and receivephases lead to fundamentally different kinds of IPCs. For example, including both a sendand a receive phase with no timeout implements a synchronous IPC that blocks untila reply is received, while an IPC that includes only a receive phase and no (or ratherinfinite) timeout implements a blocking call that waits for a message to arrive. The L4 APIprovides convenience interfaces to these different kinds of IPC calls.
To enable implementation-specific optimizations, two variants of the IPC system callexist: normal IPC and lightweight IPC (LIPC). Functionally, both variants are identical,but LIPC may be optimized for sending messages to local threads. Transparently to theuser, a kernel implementation can unify both variants or implement differently optimizedfunctions. IPC is the default IPC function. It must always be used, except if all criteriafor using LIPC are fulfilled: both a send and receive phase are included, the destinationthread is specified as a local thread ID, the destination thread runs on the same processor,there is a short receive timeout, and the IPC includes no map/grant operations. Theserestrictions allow LIPC to be up to an order of magnitude faster than regular IPC.
31
Chapter 6
GNU Mach and L4 Differences
As you can see in previous chapters 4 and 5, there are some differences between these twoµ-kernels. Currently the Hurd runs on Mach, but as mentioned in chapter 3, there is aneffort to replace Mach with L4 or another µ-kernel, because Mach has some serious lacks.
6.1 GNU Mach
− GNU Mach is big and slow (more than 100 system calls).
− Mach runs only on IA32 systems.
IPC
• A Mach IPC message is sent to a task instead of a thread. This is because ports areshared by all the threads in a task.
• IPC is asynchronous (messages sent by IPCs are queued in kernel-level buffers).
+ Mach acts as a central object server, providing not only the facility but also definingthe policy.
− This policy makes IPC convenient, but slow.
− Message buffering requires in-copy and out-copy.
− Flexible data types require costly message analysis.
− The port right system is very heavyweight.
VMM
• Mach acts as a central virtual memory management server, not only providing accessto the physical memory but also defining the policy of virtual memory management.
− It doesn’t know enough about how the memory is used to make correct pageoutdecisions.
32
Device Drivers
• Mach has built-in device drivers.
− That means a bug in a driver can crash the whole system.
6.2 L4
+ L4 is small and very fast (Pistachio provides only 11 system calls).
+ There are L4 implementations for Alpha, AMD64, ARM, IA32, IA64, MIPS andPowerPC architecture.
IPC
• In L4, a message is always sent to a thread.
• Only primitive security mechanism.
• Every server will manage itself the objects it provides and the handles to them.
• L4 IPC is synchronous (messages are sent to target threads directly), the sendingthread blocks until the receiving thread received the message.
+ No copying necessary if all arguments fit into the registers.
+ Limited support for data types makes message analysis easy.
VMM
• L4 provides only access to the physical pages.
• Instead of implementing a single VMM server, distributed approach was proposed.
• Every task enters a contract with the memory server about guaranteed physical pagesand some extra pages.
• Guaranteed pages are renegotiated from time to time.
• Extra pages have to be returned on short notice.
• Tasks manage their own virtual memory.
Device Drivers
• L4 has no built-in device drivers — they are implemented in user-space.
− An interface for drivers is needed.
33
Chapter 7
GNU/Hurd Installation
This installation guide provides a basic instructions for native and cross installation of theDebian GNU/Hurd to x86 computer. It is to date March 31, 2006 and the guide expectsK10 version of the distribution.
7.1 About Debian GNU/Hurd
The GNU Hurd is a totally new operating system being put together by the GNU group.In fact, the GNU Hurd is the final component which makes it possible to built an entirelyGNU OS — and Debian GNU/Hurd is going to be one such (possibly even the first) GNUOS.
Debian is a free operating system. Currently, stable version of Debian is only availablewith Linux kernel, but there are a non-Linux ports such as Debian GNU/NetBSD, DebianGNU/kFreeBSD and Debian GNU/Hurd as well. Because Debian GNU/Hurd is still underactive development, therefore hasn’t been officially released yet, and won’t be for sometime.
7.2 Native Installation
7.2.1 Introduction
This section is focused to the Debian GNU/Hurd installation on x86 computer without anyoperating system. You can have already some OS installed1, but you need about 2 GB (itdepends whatever you want to install) of free space on your hard drive.
There are many ways how to install Hurd. You can use:
• a set of four CD’s,
• a one DVD,
• or a mini CD for network installation.
The best way is to use the first CD from the set for the first part of install process and thenchoose network install for the second one part.2 That is because Hurd is still unstable and
1If you have some, it is highly recommended to do complete backup of your system.2We don’t use mini CD, because it doesn’t include boot loader and some other utilities that we need for
comfortable installation.
34
a lot of packages have a new version then that in released distribution on the CDs. So it isuseless to install all packages from the CDs and then install new versions of these packagesfrom the internet.
For installation you need besides 2 GB of free space some supported network card.A relatively complete hardware compatibility guide can be found at http://www.nongnu.org/thug/gnumach_hardware.html. Don’t forget that the GNU Hurd currently runs onlyon IA32 machines!
7.2.2 CDs Preparation
CD1 of the latest Debian GNU/Hurd distribution can be downloaded from ftp://ftp.gnuab.org/pub/debian-cd/current/hurd-i386/.
Now we burn the downloaded CD1 and look up the file ./install/grub-94.iso on it.This image includes Grub boot loader that we will need for boot Hurd after install to harddrive. So we burn it as well. Now we have got two CDs (installation CD1 and the GrubCD) and we can start installation of the Debian GNU/Hurd.
7.2.3 Base System Installation — Stage One
When you boot from the CD1, then shows a welcome screen and boot: command line. Wedon’t need any special parameters, so press Enter. After boot shows Debian GNU/HurdInstallation Main Menu.
You can setup keyboard in 1st menu entry if you want or use default qwerty/us.Next is Partition a Hard Disk. We select device and then starts cfdisk. I chose this
variant:
Name Flags Part Type FS Type Size (MB)---------------------------------------------------hda1 Boot Primary Linux 1800.00hda2 Primary Linux swap 128.00
If you have already swap partition, you can share it with another OS (e.g. Linux) and youdon’t have to create another one.
Note that partition names in cfdisk are in the Linux format (because installer usesLinux kernel). GNU Mach (that Debian GNU/Hurd uses) enumerates disks starting atzero. IDE drives are prefixed with hd, while SCSI disks are prefixed with sd. Like Linux,drives are number by their position on the controller. For instance, the primary master ishd0 and the secondary slave is hd3. Partitions use the BSD slice naming convention andappend sM to the drive name to indicate a given partition. M is a one, not zero, basedindex. For example Mach’s hd0s1, hd0s2 corresponds to Linux’s hda1, hda2.
The next step is Initialize and Activate a Swap Partition. We can skip bad blocks scanand then choose /dev/hda2 as a swap partition.
Then Initialize a GNU/Hurd Partition. Again skip bad blocks scan, use /dev/hda1 andthen mount this partition as root.
The last step is Install the Base System. We select CD-ROM installation method andChoose from the list. Then the installer copy base system to your hard drive.
And finally Reboot the system.
35
7.2.4 Base System Installation — Stage Two
Now we replace CD1 with the Grub CD and boot from it. Then shows Grub boot menu.We choose fourth item:
GNU Hurd (IDE 1st partition - hd0s1 single-user)
Before you boot the system, you should check boot parameters of this item. It should belike this:
root (hd0,0)kernel /boot/gnumach.gz -s root=device:hd0s1module /hurd/ext2fs.static \
--multiboot-command-line=${kernel-command-line} \--host-priv-port=${host-port} \--device-master-port=${device-port} \--exec-server-task=${exec-task} -T typed ${root} \$(task-create) $(task-resume)
module /lib/ld.so.1 /hurd/exec $(exec-task=task-create)
First command indicates / filesystem; second command path to the kernel on that root fswith single-user flag and device name for / fs after boot.; Last two commands loads the rootfilesystem server and the exec server. This is done using Grub’s boot module capability.The ${var} are filled in by GNU Mach. For more informations about server’s options try:servername --help.
Note that we need to choose single-user mode, because Hurd installation is incompleteand system need to be set up before boot to multi-user mode.
Once you are presented with a shell prompt after boot, and any time that the Hurd isin single-user mode, it is necessary to set the terminal type:
# export TERM=mach
Be warned that Ctrl+C and family will not work in single-user mode.We can now run the native-install script. This will configure the packages and set
up several important translators and device files:
# ./native-install
Before the script terminates, it need to choose timezone, so we can choose 8 for Europeand type e.g. Prague. Then the script will indicate that it needs to be run a second time.Follow its instructions and reboot using the reboot command. Again, go into single-usermode and put into the command line:
# export TERM=mach# ./native-install
In debconf configuration you can choose default values Dialog and then Medium priority.Maybe installer ask you for another questions, but everything is nicely described.Installation of the base system and configuration of basic packages is now complete.
36
7.2.5 System Configuration
Other File Systems
Next, edit /etc/fstab to add any additional filesystems as well as swap space. So we addat least our swap space partition that we already created. After that, /etc/fstab will looklike this:
# <file system> <mount point> <type> <options> <dump> <pass>/dev/hd0s1 / ext2 rw 1 1/dev/hd0s2 none swap none 0 0
Note that nano is the only editor installed by the the base distribution. You can use simplycat as well.
Remember to create any devices using the MAKEDEV command:
# cd /dev# ./MAKEDEV hd0 hd0s1 hd0s2 hd2
hd0 is whole hard drive (primary master); hd0s1 is our root filesystem; hd0s2 is our swappartition; and hd2 is CD-ROM drive (you can replace it with your CD-ROM device name).
To mount an NFS filesystem, /hurd/nfs translator is used. When run as non-root,the translator will connect to the server using a port above 1023. By default, GNU/Linuxwill reject this. To tell GNU/Linux to accept connections originating from a non-reservedport, add the insecure option to the export line. Here is an example /etc/exports fileassuming the client’s IP address is ‘192.168.1.2’:
/home 192.168.1.2(rw,insecure)
To mount this from a Hurd box and assuming that NFS server’s IP address is ‘192.168.1.1’:
# settrans -cgap /mount/point /hurd/nfs 192.168.1.1:/home
Rebooting
Finally, we can reboot into multi-user mode. It means that we choose in the Grub bootmenu third item:
GNU Hurd (IDE 1st partition - hd0s1 multi-user)
Note that multi-user entry is the same as singe-user that has just one more -s option whenloading the kernel.
When the system starts up in multi-user mode, you can login as root with:
login> l root
The Network
To configure the network, the pfinet translator must be configured. This is done usingthe settrans command to attach a translator to a given filesystem node. When programsaccess the node by, for example sending an RPC, the operating system will transparentlystart the server to handle the request. For example, we can set up network like this:
37
# settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 \-a 192.168.1.2 -m 255.255.255.0 -g 192.168.1.1
Here, settrans is passed several options. The first two, fg, force any existing translatorto go away. The next two, ap, make both active and passive translators. By making thetranslator active, we will immediately see any error messages on stderr. The latter, savesthe translator and arguments in the node so it can be transparently restarted later (i.e.making the setting persistent across reboots). The options are followed by the node towhich the translator is to be attached3, then the program (i.e. translator) to run and anyarguments to give it. The -i option is the interface4 pfinet will listen on, -a is the IPaddress, -m is the network mask and -g is the gateway.
Be sure to add name servers to the /etc/resolv.conf file, in our case:
nameserver 192.168.1.1
To test the configuration we can ping the gateway:
# ping -c3 192.168.1.1
Help on settrans can be obtained by passing it the --help option. Help on a specifictranslator can be gotten by invoking it from the command line with the same argument,e.g.:
# /hurd/pfinet --help
7.2.6 Final Words
The Hurd Console
Besides the Mach console you encountered during installation, the GNU/Hurd featuresa powerful user-space console providing virtual terminals. Currently, you have to start theHurd console manually with the following command:
# console -d vga -d pc_kbd -d pc_mouse -d generic_speaker -c /dev/vcs
Inside the Hurd console, you can switch between virtual terminals via Alt+F1, Alt+F2and so on. Ctrl+Alt+Backspace detachs the Hurd console and brings you back to the Machconsole, from where you can reattach again with the above command.
The Grub Installation
It is a good idea to install the Grub boot loader to MBR on the hard drive. We need for itthe Grub CD, that we have in CD-ROM drive (in my case it is device /dev/hd2):
# mkdir /cdrom# settrans -a /cdrom /hurd/iso9660fs /dev/hd2# cp -R /cdrom/boot/grub /boot# settrans -g /cdrom
3 /servers/socket/1 is used for loopback device. Setting for network card is always placed in/servers/socket/2, because that is where glibc will look for it.
4If you would like configure multiple network interfaces, for example eth0 and eth1, you can usesettrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a ... -i eth1 -a ...
38
The first one command creates direcory for mount CD-ROM; the second one sets the activetranslator (mounts CD-ROM filesystem); third one copies Grub files to the hard drive; andthe last one asks the active translator to go away (unmounts CD-ROM).
Now you can edit /boot/grub/menu.lst and change timeout, default entry to boot,etc.
The last step that we need is write the Grub to MBR. The easiest way is reboot thesystem, again boot from the Grub CD and choose the fifth item:
Install GRUB into hd0 MBR
And that is all. Now you can boot from the hard drive.
Adding Devices
By default, only a few devices are created in the /dev directory. Use the MAKEDEV script tocreate any needed device nodes.
Installing More Packages
There are several ways to add packages. Downloading and using dpkg -i works but is veryinconvenient. The easiest method is to use dselect, but first of all it is necessary configureapt. We use internet for upgrading and installing new packages as I mentioned in 7.2.1. Sowe need to edit /etc/apt/sources.list. The file should look like this:
deb http://ftp.cz.debian.org/debian unstable main contribdeb http://ftp.gnuab.org/debian unreleased main
To use a local Debian mirror, visit http://www.debian.org/mirror/list. http://ftp.gnuab.org and its mirrors contain packages that have hacks or patches that have not yetbeen integrated upstream or in Debian.
Now we can run:
# dselect
and choose the first item Access, then apt. Source list we have already configured, so wecan skip this step.
Update in the main menu will update list of available packages. Note that during thisprocess you can see some GPG errors. Don’t worry about it, it is fine.
When you choose Select, the dselect automatically marks common packages to install(e.g. cron, manpages, gcc, wget, etc.). You can select another packages that you need (mc,bzip2, . . . ).
Now select Install. You can see that a lot of common packages will be upgraded or newlyinstalled. Before downloading files some authentication warning could appear. Don’t worryand continue without verification.
That is all and henceforward the Debian GNU/Hurd should be quite usable.
Useful Tips
If you want to:
• change hostname, edit /etc/hostname.
39
• use Linux-like ifconfig for network configuration, install inetutils-tools package anduse inetutils-ifconfig command.
• run the Hurd console automatically on bootup, follow instructions in the file /etc/-default/hurd-console.
• use df command, you have to specify filesystem, e.g. df /.
• find out memory info, try vmstat.
• read kernel log, use cat /dev/klog > kernel.log and read the file. It is becauselog is readable only once.
• change the options or show the current settings of an active (filesystem) translator,use fsysopts.
More tips and FAQs you can find at http://www.gnu.org/software/hurd/faq.en.html.
7.3 Cross Installation
7.3.1 Introduction
This section explains the Debian GNU/Hurd installation on x86 computer with installedGNU/Linux system. We expect configured Debian GNU/Linux 3.1r1 “Sarge” with theGrub boot loader and 2 GB of free space on the hard drive (like in the native installation,it depends whatever you want to install).
We need also some supported network card. Like in the first case, check your hardwareat http://www.nongnu.org/thug/gnumach_hardware.html. Don’t forget that the GNUHurd currently runs only on IA32 machines!
7.3.2 Install Preparation
First of all, we need to install crosshurd package:
# apt-get install crosshurd
Note that crosshurd can now be used to install not only GNU/Hurd, but also GNU/Linux,GNU/kFreeBSD and GNU/kNetBSD, but it is outside this guide.
Next it is necessary to create a partition. You can use e.g. cfdisk for that. Partitiontable should look like this:
Name Flags Part Type FS Type Size (MB)---------------------------------------------------hda1 Boot Primary Linux ext3 1800.00hda2 Primary Linux swap 128.00hda3 Primary Linux 1800.00
On hda1 our GNU/Linux is installed; on hda2 there is swap, that we can share with bothsystems; and hda3 will be used for GNU/Hurd.
Now we can put ext2 file system on created partition:
# mke2fs -b 4096 -o hurd /dev/hda3
40
The -o hurd is necessary so that the system know that it is safe to setup translators.Review /etc/crosshurd/sources.list/gnu. Package sources should be the same as
for native installation (see content of the /etc/apt/sources.list file in 7.2.6 InstallingMore Packages).
Because the list of required packages for the GNU/Hurd in crosshurd package is quiteoutdated, it is necessary to edit /etc/crosshurd/packages/common file and replace thesenames of packages:
libdb2 → libdb3libreadline4 → readline-common
slang1 → libslang1
Now we need to mount formatted partition:
# mkdir /hurd# mount -t ext2 /dev/hda3 /hurd
7.3.3 Base System Installation
Finally, we can start GNU/Hurd installation:
# cd /hurd# crosshurd
Choose the target directory to be /hurd, the target system to be gnu, leave the target CPUat i386 and say yes for a /usr -> . symlink.
7.3.4 Grub Boot Loader Setup
It is necessary to add GNU/Hurd to Grub boot menu after installation. We can useprepared record from the /usr/share/doc/grub/examples/menu.lst file5 and copy it tothe /boot/grub/menu.lst file. The record should be the same as in 7.2.4 (only with anotherroot device name, in our case hd0s3). Note that the record is prepared for mutli-user mode,so it is recommended leave it as is. When you need to boot to single-user mode, you canmanually add -s option to the kernel in the boot menu.
It is time to reboot the system. In the boot menu we choose GNU/Hurd, that we added,and boot to single-user mode (using -s as mentioned above).
Next procedure is the same as for native installation, only with a few differences. Wecan go to 7.2.4 Base System Installation — Stage Two in Native Installation section. Beforedoing so, please read next lines!
Pay attention that in Native Installation GNU/Hurd is on hd0s1. But now we haveGNU/Linux on hd0s1 and GNU/Hurd is on hd0s3. So in the next installation procedureyou need substitute hd0s1 by hd0s3.
Because Grub boot loader is already installed and configured on the hard drive, youdon’t need the Grub CD (that is required in Native Installation section) and you cancertainly skip 7.2.6 The Grub Installation.
5If you don’t known, it is item with GNU (also known as GNU/Hurd) title.
41
Chapter 8
Current Status of the GNU/Hurd
8.1 Hurd µ-kernel Usage History
The first µ-kernel, that GNU Hurd has used, was GNU Mach, which is based on theMach 3 µ-kernel. Developers has choosen it this way, because no other µ-kernel had beenmore suitable for the Hurd. But GNU Mach has had some lacks and mainly performanceproblems, so core developers have created new experimental branch of the Hurd basedon L4Ka::Pistachio µ-kernel. Although L4Ka::Pistachio has been much faster then GNUMach, it still hasn’t got new features to offer.
That is why Hurd on L4Ka::Pistachio has been stalled and core developers think aboutnew µ-kernel again. It will be probably Coyotos1 which is a successor to the EROS2 system,or L4.Sec3, which is another implementation of the L4 µ-kernel. But both µ-kernels arestill in the design stage and can’t run, so it is quite difficult to make a decision which oneis better for the Hurd now. New experimental branch with new µ-kernel should be calledngHurd (or Hurd-NG).
Developers Marcus Brinkmann and Neal H. Walfield have started work on a propositionpaper and a technical specification of the ngHurd4. These documents should make a decisionof a new µ-kernel easier.
One of the design goals of GNU Hurd was to be platform (architecture, µ-kernel) in-dependent, but currently there are experimental ports only, as mentioned above. PortingHurd to another µ-kernel for the first time will help to be able to do that in the futureagain.
Development of the Hurd on L4Ka::Pistachio will probably continue only in the casewhen Coyotos and L4.Sec fail. Probably the Hurd on GNU Mach 1.x will continue itsdevelopment until more stable kernel is developed. The GNU/Hurd’s µ-kernel usage historywith Hurd’s releases overview is shown in figure 8.1.
About OSKit-Mach
OSKit-Mach began as a branch of the GNUMach 1.2 kernel, but since the release of GNUMach 1.3, OSKit-Mach has been merged as the new GNUMach 2.x mainline.
1Coyotos homepage: http://www.coyotos.org.2EROS homepage: http://www.eros-os.org (research effort has ended).3L4.Sec homepage: http://os.inf.tu-dresden.de/L4/L4.Sec.4A draft specification of the ngHurd iterfaces can be found at http://hurd.gnufans.org/bin/view/
Hurd/NextHurd.
42
May1991
GNU Machv 1.0Mach 3
May2002
L4Ka::Pistachio
May1997
OSKit-Machinitial version
GNU Machinitial version
Apr1997
GNU Machv 1.1
Jun1999
GNU Machv 1.2
OSKit-Machfuture GNU Mach 2.0
GNU Machv 1.3
Nov2002
Apr2006
Whatnext?
GNU Mach(continue)
L4Ka::Pistachio(stalled)
OSKit-Mach(stalled)
? Coyotos ?(probably)
? L4.Sec ?
? L4ng ?
GNU Hurdv 0.3
GNU Hurdv 0.2
GNU Hurdv 0.1
GNU Hurdinitial version
Jun1997
Sep1996
Jun20021991
Figure 8.1: Hurd’s µ-kernel usage history and Hurd’s releases overview
GNU Mach 2.0 makes use of the drivers provided by the OSKit from the Flux ResearchGroup. The OSKit provided a neat driver base where both FreeBSD and Linux (2.2.12)drivers are made available to Mach and thus the Hurd. However, OSKit isn’t maintainedanymore.
The OSKit-Mach version of GNU Mach is more or less defunct today (2006). Nobody isworking on it. Few people ever got it running, and by now there are also problems buildingit with recent toolchains.
Homepage: http://hurd.gnufans.org/bin/view/Mach/OskitMach
About Coyotos
Coyotos is a secure, microkernel-based operating system that builds on ideas and experi-ences of EROS (Extremely Reliable Operating System) project. Much of the code developedfor EROS will migrate directly to Coyotos.
The Coyotos project has several goals:
• Correct some of the shortcomings of the earlier EROS design.
• Demonstrate that an atomic kernel design scales up as well as down. They are plan-ning to bring up versions of Coyotos on large-scale multiprocessors.
• Provide an efficient Linux compatibility environment for use as a transitional runtimesystem, so that we can explore adapting applications to a more secure API foundation.
43
• Construct the kernel and key utilities in a new system programming language (BitC)with a well-defined, mechanically-specified semantics. This will allow us to formallyverify security and correctness properties of the system and its key utilities.
• Develop the proving technology necessary to do useful verification about a project ofthis sort.
System is being developed on AMD-64 and Pentium platforms. A port is also underwayto recent Coldfire processors. Support for PowerPC and ARM processors is expected aswell.
Coyotos is still in the design stage and no release is available today.
Homepage: http://www.coyotos.org
About L4.Sec
L4.Sec is a specification of next generation µ-kernel interface targeted to co-host user-level servers implementing security-critical functionality next to untrusted and potentiallymalicious software.
L4.Sec is still in the design stage and no release is available today.
Homepage: http://os.inf.tu-dresden.de/L4/L4.Sec
8.2 Known Flaws and Limitations
Note that the following list of known limitations is for the GNU/Hurd with the GNU Machµ-kernel (that is used in the Debian GNU/Hurd distribution).
• 1.5+ GB ext2 partition size limit.
– The problem is fixed in the Debian GNU/Hurd distribution.
• Missing device drivers.
– Current GNU Mach drivers are from Linux 2.0.
– OSKit-Mach currently has Linux 2.2 drivers.
• Swap is highly recommended, like on UNIX systems.
• Minimum of 8 MB RAM has been reported to work, but 32 MB is more realistic.Don’t forget to use plenty of swap space.
• 768 MB RAM maximum approximately. If you have got too much use Grubs’suppermem command to limit the amount seen by Mach.
• Random devices, /dev/random and /dev/urandom, are not in the main distributionyet. These are needed by, for instance, OpenSSH.
• There are some system API limits.
• No interface for userspace non-critical drivers.
• Sound support missing.
44
– OSKit-Mach can provide, but no work yet.
• PPP is currently supported, but is not stable.
• USB support is missing.
• No scanners are currently supported.
• No ACPI support.
• No WLAN support.
• XFree86 is stabilizing.
• X.Org is available in the Debian GNU/Hurd distribution.
• fatfs translator is available, and it doesn’t have partition limits that get in the way.
• Ext3 implementation is very unstable.
• Portability between alternate microkernels, e.g. L4Ka::Pistachio
• Stability issues.
8.3 Linux-related L4 Based Projects
L4Linux
L4Linux is a port of the Linux kernel to the L4 µ-kernel API. It is a (para-)virtualizedLinux running on top of a hypervisor, completely without privileges if wanted.
L4Linux runs in user-mode on top of the µ-kernel, side-by-side with other µ-kernel appli-cations such as real-time components. It is binary-compatible with the normal Linux/x86kernel and can be used with any PC-based Linux distribution.
Several releases of L4Linux are available, based on different Linux versions (currently2.6.16, 2.4.30, 2.2.26 and 2.0.21). Only 2.6.x branch is currently mantained.
Homepage: http://os.inf.tu-dresden.de/L4/LinuxOnL4
Fiasco-UX µ-kernel
Fiasco-UX is a port of the Fiasco microkernel to the Linux system-call interface. Due toits special design, it runs without kernel-level privileges, despite the fact that it is a fullyfunctional L4 microkernel. Because it uses GNU/Linux as host system, it can run on anyx86-based system as a normal user-mode application.
Supported Linux kernels are from 2.2.x up to 2.6.x (earlier kernels untested).
Homepage: http://os.inf.tu-dresden.de/fiasco/ux
45
Chapter 9
Epilogue
This project describes the GNU Hurd operating system. The Hurd project exists overfifteen years, but its development is very very slow and stable version hasn’t been releasedyet. That is because main goals of the Hurd are especially stability, security and freedom,but it is not so easy to implement all these features together. The Hurd is really differentfrom other UNIX and UNIX-like systems. You can find a lot of stable and secure UNIXes,but if you take the last mentioned goal, freedom, it is unique just for the Hurd. The freedomhere is understood as freedom of user, so he is limited as less as possible, so he can reallyexperiment under OS as he wants, for example to write his own filesystem server or devicedriver and he does not need administrator permitions and even do not need to reboot hiscomputer.
On the other side, the Hurd’s concept of servers causes the whole system to be a bitslower. The interprocess communication is in a trouble here and optimising it can greatlyhelp. Therefore there is an effort to replace original GNU Mach µ-kernel. L4Ka::Pistachio µ-kernel has solved the interprocess communication problem, but core developers furthermoreneed new features that are required for successful implementation of the Hurd according tosystem vision, so there is a discussion about another µ-kernel that will be more suitable forthe Hurd. There are thoughts about Coyotos, the successor of the EROS or L4.Sec (bothnot complete yet). They are also indications of completely new µ-kernel that should becreated especially for the Hurd.
It is a pity that only a few developers currently work on the Hurd and furthermore theyhave not got too much time, so development is practically suspended nowadays. For surethe GNU Hurd is a good idea and I hope that this great system will be released as a stableversion one day.
46
Bibliography
[1] Introduction to the translator concept. DEBIAN.ORG — The Universal OperatingSystem, [online], [cit. 2006-04-23].URL: http://www.debian.org/ports/hurd/hurd-doc-translator
[2] Preliminary GNU/Hurd User Interface Description. DEBIAN.ORG — The UniversalOperating System, [online], [cit. 2006-04-23].URL: http://www.debian.org/ports/hurd/hurd-doc-server
[3] Debian GNU/Hurd Installation. DEBIAN.ORG — The Universal Operating System,[online], [cit. 2006-04-23].URL: http://www.debian.org/ports/hurd/hurd-install
[4] Hurd Installation Guide. University of Warwick Hurd User Group, [online], Last up-date 2006-03-01, [cit. 2006-04-23].URL: http://uwhug.org.uk/index.pl?Hurd_Installation_Guide
[5] WALFIELD, N. H.: The Hurd Installation Guide. [online], Last update 2003-01-21,[cit. 2006-04-23].URL: http://web.walfield.org/pub/people/neal/papers/hurd-installation-guide/english/hurd-install-guide.html
[6] BRINKMANN, M.: How to Install Hurd. In OpenWeekend 2004 — Video archive,Prague, Czech Republic, 2004, [online], [cit. 2006-04-23].URL: http://avc.sh.cvut.cz/archiv/index.php?id=1041&rid=39&offset=0&select=OpenWeekend
[7] Known Limitations and Fixes of Hurd. The Hurd Wiki, [online], [cit. 2006-04-23].URL: http://hurd.gnufans.org/bin/view/Hurd/KnownHurdLimits
[8] GOLUB, D. B.; DEAN, R. W.; FORIN, A.; RASHID, R. F.: Unix as an ApplicationProgram. In Proceedings of the Summer 1990 USENIX Conference, June 1990, [online],[cit. 2006-04-23].URL: http://citeseer.ist.psu.edu/golub90unix.html
[9] KUZ, I.: L4 User Manual — API Version X.2. c©2004 National ICT Australia, [online],Version 1.9 (September 23, 2004), [cit. 2006-04-23].URL: http://ertos.nicta.com.au/publications/papers/L4UM_x.2.pdf
47
[10] The L4 Microkernel Family. Operating Systems Group TU Dresden, [online], [cit. 2006-04-28].URL: http://os.inf.tu-dresden.de/L4
[11] MIGNOT, G. L.: The GNU Hurd. In Libre Software Meeting July 5–9, Dijon, France,2005, [online], [cit. 2006-04-23].URL: http://kilobug.free.fr/hurd/pres-en/abstract/abstract.pdfURL: http://kilobug.free.fr/hurd/pres-en/slides/slides.html
[12] BRINKMANN, M.: The GNU Hurd — Lessons and Perspective. In OpenWeekend2004 — Collection of Talks, Prague, Czech Republic, 2004, p. 37–40, [online], [rev.2004-10-03], [cit. 2006-04-23].URL: http://www.openweekend.cz/download/sbornik_ow2004.pdf
48
