Minix — реинкарнация?

Goals of the project

Structure of monolithic kernel and microkernel-based operating systems, respectively

Reflecting on the nature of monolithic kernel based systems, where a driver (which has, according to MINIX creator Tanenbaum, approximately 3–7 times as many bugs as a usual program) can bring down the whole system, MINIX 3 aims to create an operating system that is a «reliable, self-healing, multiserver Unix clone».

To achieve that, the code running in kernel must be minimal, with the file server, process server, and each device driver running as separate user-mode processes. Each driver is carefully monitored by a part of the system named the reincarnation server. If a driver fails to respond to pings from this server, it is shut down and replaced by a fresh copy of the driver.

In a monolithic system, a bug in a driver can easily crash the whole kernel. This is far less likely to occur in MINIX 3.

Reliability policies

One of the main goals of MINIX 3 is reliability. Below, some of the more important principles that enhance its reliability are discussed.

Reduce kernel size

Monolithic operating systems such as Linux and FreeBSD and hybrids like Windows have millions of lines of kernel code. In contrast, MINIX 3 has about 6,000 lines of executable kernel code, which can make problems easier to find in the code.

Cage the bugs

In monolithic kernels, device drivers reside in the kernel. Thus, when a new peripheral is installed, unknown, untrusted code is inserted in the kernel. One bad line of code in a driver can bring down the system.

Instead, in MINIX 3, each device driver is a separate user-mode process. Drivers cannot execute privileged instructions, change the page tables, perform arbitrary input/output (I/O), or write to absolute memory. They must make kernel calls for these services and the kernel checks each call for authority.

Limit drivers’ memory access

In monolithic kernels, a driver can write to any word of memory and thus accidentally corrupt user programs.

In MINIX 3, when a user expects data from, for example, the file system, it builds a descriptor telling who has access and at what addresses. It then passes an index to this descriptor to the file system, which may pass it to a driver. The file system or driver then asks the kernel to write via the descriptor, making it impossible for them to write to addresses outside the buffer.

Survive bad pointers

Dereferencing a bad pointer within a driver will crash the driver process, but will have no effect on the system as a whole. The reincarnation server will restart the crashed driver automatically. Users will not notice recovery for some drivers (e.g., disk and network) but for others (e.g., audio and printer), they might. In monolithic kernels, dereferencing a bad pointer in a driver normally leads to a system crash.

Tame infinite loops

If a driver gets into an infinite loop, the scheduler will gradually lower its priority until it becomes idle. Eventually the reincarnation server will see that it is not responding to status requests, so it will kill and restart the looping driver. In a monolithic kernel, a looping driver could hang the system.

Limit damage from buffer overflows

MINIX 3 uses fixed-length messages for internal communication, which eliminates certain buffer overflows and buffer management problems. Also, many exploits work by overrunning a buffer to trick the program into returning from a function call using an overwritten stack return address pointing into attacker controlled memory, usually the overrun buffer. In MINIX 3, this attack is mitigated because instruction and data space are split and only code in (read-only) instruction space can be executed, termed executable space protection. However, attacks which rely on running legitimately executable memory in a malicious way (return-to-libc, return-oriented programming) are not prevented by this mitigation.

Restrict access to kernel functions

Device drivers obtain kernel services (such as copying data to users’ address spaces) by making kernel calls. The MINIX 3 kernel has a bit map for each driver specifying which calls it is authorized to make. In monolithic kernels, every driver can call every kernel function, authorized or not.

Restrict access to I/O ports

The kernel also maintains a table telling which I/O ports each driver may access. Thus, a driver can only touch its own I/O ports. In monolithic kernels, a buggy driver can access I/O ports belonging to another device.

Restrict communication with OS components

Not every driver and server needs to communicate with every other driver and server. Accordingly, a per-process bit map determines which destinations each process may send to.

Reincarnate dead or sick drivers

A special process, called the reincarnation server, periodically pings each device driver. If the driver dies or fails to respond correctly to pings, the reincarnation server automatically replaces it with a fresh copy. Detecting and replacing non-functioning drivers is automatic, with no user action needed. This feature does not work for disk drivers at present, but in the next release the system will be able to recover even disk drivers, which will be shadowed in random-access memory (RAM). Driver recovery does not affect running processes.

Integrate interrupts and messages

When an interrupt occurs, it is converted at a low level to a notification sent to the appropriate driver. If the driver is waiting for a message, it gets the interrupt immediately; otherwise it gets the notification the next time it does a to get a message. This scheme eliminates nested interrupts and makes driver programming easier.

История

MINIX 3 был анонсирован 24 октября 2005 года Эндрю Таненбаумом во время его вступительной речи на симпозиуме о принципах операционных систем ACM. Хотя MINIX 3 все ещё служит в качестве примера для нового издания книги Таненбаума и Вудхалла, он все же был переработан, чтобы быть «удобным в использовании как надёжная операционная система для встраиваемых устройств и устройств с ограниченными ресурсами, для задач требующих высокой надёжности».

Примечания

1. (unspecified title)
2. Wagstrom, Patrick. Minix under VMWare Installation How-To. 8 Jul 2006  (недоступная ссылка). Дата обращения 1 мая 2014. .
3. Tanenbaum, Andy . OSnew. OSnews (25 сентября 2006). — «From Rebirth section: «Various studies have shown that software broadly contains something like 6-16 bugs per 1000 lines of code and that device drivers have 3-7 times as many bugs as the rest of the operating system. When combined with the fact that 70% of a typical operating system consists of device drivers, it is clear that device drivers are a big source of trouble. For Windows XP, 85% of the crashes are due to bugs in device drivers. Obviously, to make OSes reliable, something has to be done to deal with buggy device drivers. Building a reliable system despite the inevitable bugs in device drivers was the original driving force behind MINIX 3.»». Дата обращения 4 июля 2008.
4. ↑
5. . wiki.minix3.org. Дата обращения 29 февраля 2012.

Реинкарнация?

Так все-таки имеет ли право на реинкарнацию Minix? Я думаю, да, Minix имеет право не только на существование в качестве реликта. Изначально Minix создавалась как обучающая операционная система, и с этой задачей она прекрасно справляется.

Minix3 была разработана с целью обеспечения высокой надежности, гибкости и безопасности при работе. Она основана на предыдущих версиях Minix, но существенно отличается многими ключевыми свойствами. Начиная с версии Minix 3.1.1 эту операционную систему можно использовать и для встраиваемых (embedded) систем.

Все исходные тексты Minix снабжены прекрасными комментариями. Ни в одной операционной системе больше нет таких комментариев, читая которые, можно понять устройство ядра. Также Minix остается очень маленькой операционной системой, и с ее помощью можно научиться работать в UNIX-системах буквально за одну неделю.

Minix3 можно запустить на очень «древних» машинах (начиная с процессора Intel 386). Поэтому, если у вас завалялся старый компьютер, не спешите его выбрасывать — он еще может послужить…

Так что, старина Minix, с воскрешением!

Не нашли ответ на свой вопрос? Воспользуйтесь поиском…

Отношения с Linux

Раннее влияние

Торвальдс использовал и оценил MINIX, будучи студентом у Таненбаума, однако при реализации дизайна ядра Linux решил не использовать архитектуру MINIX, применив архитектуру монолитного ядра вместо архитектуры микроядра. Данное решение Торвальдса было не одобрено Таненбаумом и вылилось в спор Таненбаума — Торвальдса. Таненбаум представил свои аргументы в пользу использования архитектуры микроядра в мае 2006 года.

Ранняя разработка ядра Linux была выполнена на хост-системе MINIX, что привело к тому, что Linux включил в себя различные функции из MINIX, такие как поддержка файловой системы MINIX.

Утверждение Кеннета Брауна

В мае 2004 года Кеннет Браун из Института Алексиса де Токвиля выдвинул обвинение в том, что основные части ядра Linux были скопированы из кодовой базы MINIX, объявив это в своей книге «Самиздат». Эти обвинения были опровергнуты — в первую очередь, Эндрю Таненбаумом, который сильно критиковал Кеннета Брауна, и опубликовал длинное опровержение на своём личном веб-сайте, также указывая на то, что Браун финансировался Microsoft.

What do we know about Intel ME? How is it related to Minix?

Intel ME and the software running on top of it are close sourced, and people having access to the related information are bound by a non-disclosure agreement. But thanks to independent researchers we still have some information about it.

Intel ME shares the flash memory with your BIOS to store its firmware. But unfortunately, a large part of the code is not accessible by a simple dump of the flash because it relies on functions stored in the inaccessible ROM part of the ME microcontroller. In addition, it appears the parts of the code that are accessible are compressed using non-disclosed Huffman compression tables. This is not cryptography, its compression— obfuscation some might say. Anyway, it does not help in reverse engineering Intel ME.

Up to its version 10, Intel ME was based on ARC or SPARC processors. But Intel ME 11 is x86 based. In April, a team at Positive Technologies tried to analyze the tools that Intel provides to OEMs/vendor as well as some ROM bypass code. But due to Huffman compression, they weren’t able to go very far.

However, they were able to do was to analyze TXE, the Trusted Execution Engine, a system similar to Intel ME, but available on the Intel Atom platforms. The nice thing about TXE is the firmware is not Huffman encoded. And there they found a funny thing. I prefer quoting the corresponding paragraph in extenso here:

Let make things clear: TXE contains code “borrowed” from Minix. That’s sure. Other hints suggest it probably runs a complete Minix implementations. Finally, despite no evidence, we can assume without too many risks that ME 11 would be based on Minix too.

Until recently Minix was certainly not a well known OS name. But a couple of catchy titles changed that recently. That and a recent open letter by Andrew Tannenbaum, the author of Minix, are probably at the root of the current hype around Intel ME.

Различия между MINIX 3 и предыдущими версиями

Основная статья: MINIX

История взаимодействий различных Unix-подобных систем

MINIX 1, 1.5 и 2 были созданы как инструменты для обучения проектированию ОС.

MINIX 1.0 был создан в 1987 году. 12 000 строк исходного кода ядра было написано преимущественно на языке программирования Си и на языке ассемблера. Исходный код ядра, файловая и система управления памятью были напечатаны в книге. Изначально Таненбаум создал MINIX для компьютеров IBM PC и IBM PC/AT, доступных в то время.

MINIX 1.5, выпущенный в 1991 году, включал в себя поддержку MicroChannel IBM PS/2 и был также портирован на архитектуры Motorola 68000 и SPARC, поддерживающие Atari ST, Commodore Amiga, Apple Macintosh и Sun Microsystems SPARCstation компьютерные платформы. Также доступна версия MINIX, работающая как пользовательский процесс под SunOS.

MINIX 2, выпущенная в 1997 году, была доступна только для архитектур x86 и запускаемая под ОС Solaris SPARC архитектурой. Minix-vmd был создан двумя исследователями из Vrije Universiteit, с добавлением виртуальной памяти и с поддержкой для X Window System.

MINIX 3 делает то же самое, обеспечивая современную ОС множеством новых инструментов и Unix приложений. Профессор Таненбаум однажды сказал:

MINIX 3.2.0 была выпущена в феврале 2012 года. Данная версия имеет множество новых возможностей, в том числе и компилятор Clang, экспериментальную симметричную многопроцессорную поддержку, procfs и ext2fs поддержку файлов и GDB. Некоторые части NetBSD были также включены в релиз, в том числе загрузчик, libc и различные другие библиотеки.

Релиз MINIX 3.2.1 вышел 21 февраля 2013 года.

Архитектура

Архитектура MINIX 3

Как можно увидеть, нижним уровнем является микроядро, состоящее из около 4000 строк кода (в основном на языке Си и небольшое количество на языке ассемблера). Оно обрабатывает прерывания, осуществляет планирование и передачу сообщений. Также он поддерживает API из примерно 30 вызовов ядра, которые сервис или драйвер могут выполнить. Пользовательская программа не может делать такие вызовы. Вместо этого они могут делать системные вызовы стандарта POSIX, которые посылают сообщение сервисам. Вызов ядра выполняет такие функции, как настройка прерываний и копирование данных между адресными пространствами.

На следующем уровне находятся драйвера устройств, каждый из которых работает как отдельный пользовательский процесс. Каждый из них управляет определёнными устройствами ввода-вывода, такими как диск или принтер. У драйвера нет доступа к портам ввода-вывода и он не может давать прямые инструкции. Вместо этого, они должны сделать системный вызов со списком портов ввода-вывода и значениями для записи. Эта схема, доставляя небольшие накладные расходы (около 500 наносекунд), позволяет ядру проверять разрешения, так что, например, аудио-драйвер не сможет записывать данные на диск.

На следующем уровне находится сервер. Там размещены почти все функциональные возможности ОС. Пользовательские процессы работают с файлами, например, путём отправки сообщения на файловый сервер для открытия, закрытия, чтения и записи файлов. В свою очередь, файловый сервер получает ввод-вывод предназначенный для отправки сообщения на драйвер диска, который фактически управляет диском.

Одним из ключевых серверов является сервер реинкарнации. Его задача состоит в опросе всех серверов и драйверов для периодической проверки их работоспособности. Если компоненты отвечают некорректно, то они попадают в бесконечный цикл, реинкарнационный сервер (который является родительским процессом для драйверов и серверов) уничтожает неисправный компонент и заменяет его на новую копию. В этом случае, система автоматически становится самовосстанавливающейся без вмешательства работающих программ.

В настоящее время сервер реинкарнации, файловый сервер, сервер процессов и микроядро являются частью доверенной вычислительной базы. Если любой из них падает, то вся система выходит из строя. Тем не менее, снижение вычислительной базы с 3-5 миллионов строк кода в Linux или 20000 строк Windows значительно повышает надежность системы.

History

MINIX 3 was publicly announced on 24 October 2005 by Andrew Tanenbaum during his keynote speech on top of the Association for Computing Machinery (ACM) Symposium Operating Systems Principles conference. Although it still serves as an example for the new edition of Tanenbaum and Woodhull’s textbook, it is comprehensively redesigned to be «usable as a serious system on resource-limited and embedded computers and for applications requiring high reliability.»

Рождение Linux и критика монолитного ядра

26 лет назад изучение программирования для Unix было нетривиальным делом для обычного студента, так как все разновидности Unix были платными. Чтобы освоить эту операционную систему Линус решает поставить Minix. Интернет в ту пору еще только зарождался, заказ ОС шел через обычную почту, так же как и доставка. Ради Minix пришлось раскошелиться на 169 долларов.

Вскоре будущий создатель Linux обнаружил серьезные недостатки Minix. Так как это был всего лишь обучающий вариант Unix, то профессор преднамеренно исковеркал ее. Многие из этих недостатков можно было устранить заплаткой самого известного хакера Minix Брюса Эванса, но для того, чтобы ее поставить нужно было изрядно провозиться. Самым же существенным недостатком для Линуса была программа эмуляции терминала, которую пришлось заменить на свою собственную. Затем понадобился драйвер файловой системы и понеслось, ядро новой ОС зародилось по принципу каши из топора.

Эндрю Таненбаум до поры до времени никак на это не реагировал, но Linux рос как снежный ком. Уже в январе 1992 г. вышла версия 0.12, в котором была реализована страничная подкачка на диск — то чего не было в Minix. Вскоре после этого профессор снизошел до выскочки, чтобы лично ему ответить и вот 29-го января Линус получает сообщение в конференцию с нравоучительным содержанием. Начало было обнадеживающим.

Далее следовали справочные сведения о монолитном ядре, микроядре и об ОС, исповедующих тот, или иной принцип. Затем следовал несостоятельный с точки зрения логики довод о том, что среди специалистов по разработке операционных систем споры по данному вопросы уже прекратились ввиду явного преимущества микроядра. Дальше декларации о том, что Minix прогрессивна, а Linux — возврат в 1970-е. Кроме того, Linux привязан к одной архитектуре в то время как Minix был перенесен с Intel процессоров на другие платформы: Atari, Amiga, Macintosh, SPARC и NS32016.

В начале 90-х микроядро действительно было в фаворе у проектировщиков операционных систем. По их мнению ядро ОС должно быть минимальным и содержать лишь самое необходимое: управление памятью, планировщик и IPC, а все остальное реализуется в виде сервисов. Разбив целое на множество простых частей, сложность исчезает, а легковесные сервисы без труда обмениваются данными с микроядром. Сбой в драйвере файловой системы или сетевой карты, таким образом элементарно восстанавливался перезагрузкой соответствующего сервиса.

Линус принимает вызов

Линус придерживался другого мнения на сей счет. Отдавая должное элегантности и изяществу архитектуры микроядра с теоретической точки зрения, он тем не менее считал микроядро не пригодным для практических целей. Мнимая простота микроядра оборачивается тем, что взаимодействие и интерфейс между простыми частями микроядра создает сложности, которые нивелируют все ее «бумажные» преимущества. В своем ответе он изложил свое видение по данному вопросу. После дерзких выпадов против своего оппонента Линус переходит к сути.

Затем перечисляет проблемы Minix с многозадачностью в файловой системе.

Перепалка в конференции продолжается, в спор вступают новые участники. Эндрю Таненбаум и Линус Торвальдсь продолжают спор, но уже более в более сдержанной манере. Ниже вольный перевод избранных цитат.

На этом первая часть Марлезонского Балета завершилась. Первый раунд битвы остался за профессором, Линус взял свои слова обратно, первым вышел из спора, однако не изменил своего мнение, так в главном он был прав — его ОС выигрывала, потому что была готова. Спустя 14 лет спор знаменитого теоретика и практика продолжился.