MINIX 3 — это проект по созданию небольшой высоконадёжной и функциональной Unix-подобной операционной системы . Он был опубликован под лицензией BSD и является наследником ранее созданных операционных систем MINIX 1 и MINIX 2.

Главной целью проекта является создание отказоустойчивой системы, способной обнаруживать и исправлять собственные ошибки «на лету» без непосредственного вмешательства пользователя. В основном, предполагалось использовать операционную систему во встраиваемых системах и образовании.

MINIX 3 в настоящее время поддерживает IA-32 архитектуру PC-совместимых компьютеров . Кроме того, возможен запуск MINIX под эмуляторами и виртуальными машинами , такими как Bochs , VMware Workstation , Microsoft Virtual PC и QEMU . Порты для архитектур ARM и PowerPC находятся в разработке.

Распространяется в виде образа операционной системы, загружаемой со сменного носителя ( Live CD ).

Цели проекта

Учитывая природу систем, основанных на монолитном ядре , где драйвер (который содержит, по словам создателя MINIX 3 Таненбаума , примерно в 3-7 раз большее количество ошибок, чем обычная программа) может обрушить всю систему, MINIX 3 направлен на создание такой операционной системы, которая была бы «надежным, самовосстанавливающимся и многосерверным UNIX- клоном ».

Чтобы достичь этого, код, выполняющийся в режиме ядра, должен быть минимальным, а файловый сервер, сервер процессов и каждый драйвер устройства должны выполняться как отдельные процессы в пользовательском режиме. Каждый драйвер тщательно контролируется частью системы, известной как сервер восстановления. Если драйвер не реагирует на пинги от сервера восстановления, то он закрывается и заменяется новой копией.

В монолитной системе ошибка в драйвере может привести к разрушению всего ядра, что значительно менее вероятно в MINIX 3.

История

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

Version	Release date	Description
3.1.0	2005-10-24	Первый релиз MINIX 3 (Выпуск книги)
3.1.2a	2006-05-29	Новый менеджер пакетов Packman Исправлена проблема установки с автоматическим разбиением дисков
3.1.3	2007-04-13	Добавлена новая виртуальная файловая система
3.1.3a	2007-06-08	Исправление ошибок
3.1.4	2009-06-09	Поддержка виртуальной памяти Улучшена поддержка виртуальной машины (где MINIX запускается как гость)
3.1.5	2009-11-05	Улучшение производительности Разделяемая память Функция setitimer Файловая система ISO 9660 Open Sound System Ловушка доступа к неинициализированным указателям NULL для удобства пользователя Улучшена обработка сигналов Лучшая поддержка для отладчиков (усовершенствованный и др.) Автоопределение сетевых карт (для поддерживаемых PCI -карт), улучшение конфигурации сети
3.1.6	2010-02-08	Новые сетевые драйверы: Atheros L2, Intel E1000, Realtek 8169, DEC Tulip PipeFS — removed pipe handling from filesystem drivers — поддержка для монтирования общих папок VMware как файловой системы VFS : supplemental group support и поддержка атрибута sticky bit Поддержка математического сопроцессора Фрэймворк системных событий (SEF) Экспериментальная поддержка APIC
3.1.7	2010-06-16	Userspace scheduling and a scheduling server Поддержка нескольких сетевых карт одного типа Загрузка образов системы > 16 MB Использование GCC Поддержка кодировок cp1251 и koi8-u
3.1.8	2010-10-04	Новая инфраструктура управления пакетами: pkgsrc и pkgin Поддержка сокета домена Unix Мультизагрузка Поддержка ext2 Драйвер ACPI Полная поддержка APIC , включая APIC I/O Экспериментальная поддержка AHCI
3.2.0	2012-02-29	Портирование GNU Debugger для MINIX 3 и реализация поддержки дампа ядра Поддержка FUSE с экспериментальной NTFS-3G Частичная замена пространства пользователя MINIX на NetBSD реализацию Замена стандартного компилятора ACK на Clang ( GCC также поддерживается) Switch to ELF and NetBSD libc libraries Pkgsrc Upstreaming and Application Porting Асинхронный (VFS) сервер Замена загрузчика MINIX на NetBSD Поддержка в AHCI драйвере
3.2.1	2013-02-21	Замена стандартного inet сервера на сетевой стек lwIP Transitioning towards strict BSD coding style (based on ) VBFS — поддержка монтирования VirtualBox Shared Folder как файловой системы Поддержка кросс-компиляции Поддержка
3.3.0	2014-09-16	Поддержка архитектуры ARM. Minix успешно запущен на широко распространенных одноплатных компьютерах Beagle Экспериментальная поддержка USB для Beaglebone (hub и mass storage) Кросскомпиляция для ARM и x86
Выпуск книги Старый релиз Текущий стабильный релиз Текущий разрабатываемый релиз

Ревизия сайта

С релизом MINIX 3.2.0 официальный веб-сайт был усовершенствован. Его достоинством является то, что кнопка загрузки и ссылки на другие важные страницы размещены прямо на главной странице. до сих пор ещё не получила необходимой ревизии и в настоящее время работает на MoinMoin .

Надёжность MINIX 3

Главной целью MINIX 3 является надёжность. Ниже представлены некоторые из наиболее важных принципов повышения надёжности.

Уменьшение размера ядра

Монолитные операционные системы, такие как Linux и FreeBSD , и такой гибрид, как Windows , содержат миллионы строк кода ядра . MINIX 3 имеет около 6000 строк исполняемого кода ядра, в котором проще отследить проблему в коде.

Отсечение ошибок

В монолитной ОС драйверы устройств располагаются в ядре. Это означает, что когда новое периферийное устройство загружается, неизвестный и потенциально ненадежный код вставляется в ядро. Ошибка в коде драйвера может привести к разрушению системы. В MINIX 3 каждый драйвер работает в своём процессе. Драйверы не могут выполнять привилегированных команд: модификацию таблиц страниц , произвольный ввод-вывод или же запись в память по абсолютному адресу. Они вынуждены делать вызовы ядра для этого и оно проверяет каждую команду на допустимость.

Ограничение доступа драйверов к памяти

В монолитной ОС драйвер может записать любое слово в память и таким образом может случайно испортить пользовательскую программу. В MINIX 3, когда пользователь ожидает данные, к примеру, от файловой системы, она создает дескриптор, указывающий, кто имеет доступ и к каким именно адресам. Затем он передает индекс этого дескриптора в файловую систему, которая может передать его драйверу. Файловая система или драйвер запрашивает у ядра запись через этот дескриптор, что делает невозможной для них запись адресов вне буфера.

Сохранение работоспособности дефектных указателей

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

Ручные бесконечные циклы

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

Ограничение повреждений от переполненного буфера

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

Ограничение доступа к функциям ядра

Драйверы устройств получают доступ к функциям ядра (таким, как копирование данных из пользовательского адресного пространства) через вызовы к ядру. В Миникс 3 ядро имеет битовую карту, в которой для каждого драйвера указано, какие вызовы ему разрешены. В монолитных системах каждый драйвер может вызвать любую функцию ядра, авторизовав её или нет.

Ограничение доступа к портам ввода-вывода

Ядро также обладает таблицей, в которой для каждого драйвера указано, к какому из портов ввода-вывода он имеет доступ. В результате драйвер может работать только со своими собственными портами ввода-вывода. В монолитных системах драйвер может получить доступ к портам ввода-вывода, принадлежащим другим устройствам.

Ограничение связи с компонентами ОС

Не каждый драйвер или сервер должен общаться с другими такими же драйверами или серверами. Соответственно, процесс битовой карты определяет, по каким направлениям каждый процесс может обращаться.

Восстановление остановленных или проблемных драйверов

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

Встроенные прерывания и сообщения

Когда происходит прерывание, оно преобразуется в уведомление, отправляемое соответствующему драйверу. Если драйвер ожидает сообщения, то он получает прерывание немедленно, в противном случае получит уведомление в следующий раз. Эта схема устраняет вложенные прерывания и делает написание драйвера проще.

Архитектура

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

Примечания

Ссылки