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

Когда последний раз ваш телевизор внезапно отключался или требовал, чтобы вы срочно загрузили из Web какую-нибудь программную заплатку, исправляющую критическую ошибку? В конце концов, если у вас не совсем уж древний телевизор, то, по сути, он тот же компьютер — с центральным процессором, большим монитором, какой-то аналоговой электроникой для декодирования радиосигналов, парочкой специальных устройств ввода/вывода (пульт, встроенный дисковод для кассет или DVD-дисков) и с программным обеспечением, прописанным в оперативной памяти. Этот риторический вопрос возвращает нас к одной неприятной проблеме, о которой так не любят говорить в компьютерной индустрии. Почему телевизоры, DVD-проигрыватели, MP3-плейеры, сотовые телефоны и другие электронные устройства с программным обеспечением вполне надежны и хорошо защищены, а компьютеры — нет? Конечно, тому есть немало «объяснений»: компьютеры — это гибкие системы, пользователи могут менять программное обеспечение, отрасль информационных технологий еще недостаточно развита и так далее. Но, поскольку мы живем в эпоху, когда подавляющее большинство компьютерных пользователей мало сведущи в технических вопросах, то подобные «объяснения» им не кажутся убедительными.

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

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

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

Почему системы ненадежны?

Современные операционные системы имеют две особенности, из-за которых они теряют как в надежности, так и в защищенности. Во-первых, эти ОС огромны по размеру, а, во-вторых, в них очень плохо обеспечена изоляция ошибок. Ядро Linux имеет свыше 2,5 млн. строк кода, а ядро Windows XP как минимум в два раза больше.

Одно из исследований, посвященных изучению надежности программного обеспечения, показало, что программы содержат от 6 до 16 ошибок на каждые 1000 строк исполняемого кода. Согласно результатам другого исследования, частота ошибок в программах находится в пределах от 2 до 75 на каждые 1000 строк исполняемого кода [2], в зависимости от размера модуля. Даже если исходить из самой скромной оценки (6 ошибок на 1000 строк кода), ядро Linux, по всей видимости, содержит примерно 15 тыс. ошибок; Windows XP — как минимум в два раза больше.

Хуже того, как правило, около 70% операционной системы составляют драйверы устройств, уровень ошибок в которых в три-семь раз выше, чем в обычном коде [3], поэтому приведенная выше оценка числа ошибок в ОС, скорее всего, сильно занижена. Понятно, что найти и исправить все эти ошибки просто невозможно. Более того, при исправлении одних ошибок зачастую вносятся новые.

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

Этот факт приводит нас ко второй проблеме: изоляции ошибок. Ни один человек в мире не знает все о том, как функционирует авианосец, но подсистемы авианосца хорошо изолированы друг от друга, и его засорившийся туалет никак не повлияет на работу подсистемы запуска ракет.

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

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

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

Укрепленные операционные системы

Самый консервативный подход, Nooks [4], был разработан для того, чтобы увеличить надежность существующих операционных систем, таких как Windows и Linux. Технология Nooks поддерживает монолитную структуру ядра, в которой сотни или тысячи процедур связаны вместе в одном адресном пространстве и работают в режиме ядра. Этот подход сосредоточен на том, чтобы сделать драйверы устройств (основная причина всех проблем) менее опасными.

Рис. 1. Модель Nooks. Каждый драйвер заключен в оболочку и размещается на уровне защищенного программного обеспечения. Этот уровень ведет мониторинг всех взаимодействий между драйвером и ядром

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

Цели проекта Nooks заключаются в следующем:

  • защитить ядра от ошибок в драйверах;
  • обеспечить автоматическое восстановление в случае сбоя в драйвере;
  • сделать все это путем минимальных изменений в существующих драйверах и ядре.

Защита ядра от некорректных драйверов — не главная цель. Впервые технология Nooks была реализована на Linux, но эти идеи в равной степени применимы к другим унаследованным ядрам.

Изоляция

Основное средство, позволяющее уберечь структуры данных ядра от уничтожения некорректными драйверами — это карта страниц виртуальной памяти. При работе драйвера все внешние для него страницы переводятся в режим «открыты только для чтения», благодаря чему создается отдельный домен упрощенной защиты для каждого драйвера. Таким образом, драйвер может читать структуры данных ядра, которые ему необходимы, но любая попытка напрямую изменить структуры данных ядра вызовет исключение центрального процессора, которое перехватывает менеджер изоляции Nooks. Доступ к частной памяти драйвера, где хранятся стеки, куча, структуры частных данных и копии объектов ядра, разрешен на чтение и на запись.

Посредничество

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

Nooks предоставляет оболочки как для экспортируемых, так и для импортируемых функций. Теперь, когда ядро вызывает функцию драйвера или драйвер вызывает функцию ядра, вызов на самом деле направляется оболочке, которая проверяет корректность параметров и управляет вызовом. Несмотря на то, что суррогаты (stubs) оболочки (на рис. 1 они изображаются как линии, указывающие как внутрь, так и наружу драйвера) генерируются автоматически на основе прототипов функций, тело оболочки разработчикам приходится писать вручную. В целом группа Nooks написала 455 оболочек: 329 для функций, которые ядро экспортирует, и 126 — для функций, которые экспортируют драйверы устройств.

Когда драйвер пытается модифицировать объект ядра, его оболочка копирует объект в домен защиты драйвера, то есть в его частные страницы, открытые для чтения и записи. Затем драйвер меняет копию. Если запрос был выполнен успешно, менеджер изоляции копирует модифицированные объекты обратно в ядро. Таким образом, сбой в работе драйвера или ошибка во время вызова всегда оставляют объекты ядра в корректном состоянии. Операции контроля за импортируемыми объектами специфические для каждого объекта, в силу чего группе Nooks пришлось вручную писать код для контроля 43 классов объектов, которые используют драйверы Linux.

Восстановление

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

Эта технология позволяет восстановить систему, но работавшие в момент сбоя приложения могут оказаться в некорректном состоянии. В результате работы [5] группа Nooks добавила концепцию дублирующих драйверов (shadow driver) для того, чтобы приложения могли выполняться корректно даже после сбоя драйвера.

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

Ограничения

Несмотря на то, что, согласно экспериментам, Nooks может обнаруживать 99% фатальных ошибок драйвера и 55% не фатальных, он далеко не совершенен. Например, драйверы могут выполнять привилегированные команды, которые они выполнять не должны; они могут записывать данные в некорректные порты ввода/вывода и выполнять бесконечные циклы. Более того, группе Nooks большое количество оболочек пришлось написать вручную, и эти оболочки могут содержать ошибки. Наконец, при данном подходе невозможно запретить драйверам записывать данные в любое место памяти. Тем не менее это потенциально весьма полезный шаг к повышению надежности унаследованных ядер.

Паравиртуальные машины

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

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

Была предпринята попытка адаптировать данную концепцию для организации защиты в одной операционной системе, а не между различными ОС [7]. Более того, поскольку Pentium не полностью поддерживает виртуализацию, пришлось отступить от принципа запускать в виртуальной машине операционную систему без каких-либо ее изменений. Эта уступка позволяет вносить изменения в операционную систему для того, чтобы гарантировать, что она не может делать ничего, что невозможно виртуализировать. Для того чтобы данную технологию отличать от истинной виртуализации, ее называют паравиртуализацией.

В частности, в 90-х годах группа разработчиков из университета Карлсруэ создала микроядро L4 [8]. Они смогли запустить слегка модифицированную версию Linux (L4Linux) на L4 в режиме, который можно называть видом виртуальной машины [9]. Позже разработчики выяснили, что вместо того чтобы запускать только одну копию Linux на L4, они могут запускать несколько копий. Как показано на рис. 2, эта мысль привела к идее использования одной из виртуальных машин Linux для работы прикладных программ, а другой или нескольких — для работы драйверов устройств.

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

Поскольку драйверы устройств работают на аппаратном обеспечении в режиме пользователя, основной вопрос заключается в том, как они будут выполнять ввод/вывод и обрабатывать прерывания. Физический ввод/вывод поддерживается за счет добавления примерно 3 тыс. строк кода к ядру Linux, на котором работают драйверы, благодаря чему драйверы могли использовать сервисы L4 для ввода/вывода вместо того, чтобы делать это самостоятельно. Дополнительные 5 тыс. строк кода поддерживают взаимодействия между тремя изолированными драйверами (диска, сети и шины PCI) и виртуальной машиной, в которой выполняются прикладные программы.

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

Параметры производительности показывают, что накладные расходы при использовании паравиртуализованных машин составляют около 3-8%.

Мультисерверные операционные системы

Первые два подхода предусматривают модификацию унаследованных систем. Следующие два посвящены будущим системам.

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

Мультисерверная архитектура

Для того чтобы лучше понять, в чем состоит идея мультисерверной операционной системы, обратимся к современному примеру. Как показано на рис. 3, в Minix 3, микроядро обрабатывает прерывания, предоставляет базовые механизмы для управления процессами, реализует взаимодействия между процессами и выполняет планирование процессов. Оно также предоставляет небольшой набор вызовов ядра для авторизованных драйверов и серверов, такие как чтение избранной части адресного пространства конкретного пользователя или запись в авторизованные порты ввода/вывода. Драйвер часов использует то же адресное пространство, что и микроядро, но он планируется как отдельный процесс. Ни один другой драйвер в режиме ядра не работает.

Над микроядром находится уровень драйверов устройств [10]. Каждое устройство ввода/вывода имеет свой собственный драйвер, который функционирует как отдельный процесс в своем собственном частном адресном пространстве, защищенном с помощью аппаратного модуля управления памятью (MMU). Этот уровень включает в себя процессы драйверов для диска, терминала (клавиатуры и дисплея), Ethernet, принтера, аудио и так далее. Эти драйверы работают в режиме пользователя и не могут выполнять привилегированные команды или операции чтения и записи на портах ввода/вывода компьютера. Для того чтобы получить эти сервисы, драйверы должны обратиться к ядру. Хотя такая архитектура увеличивает накладные расходы, она значительно повышает надежность.

Над уровнем драйверов устройств находится уровень сервера. Сервер файлов представляет собой программу (4,5 тыс. строк исполняемого кода), которая принимает запросы от пользовательских процессов на системные вызовы Posix, касающиеся файлов, таких как, read, write, lseek и stat, и выполняет их. Кроме того, на этом уровне расположен менеджер процессов, который управляет процессами и памятью и выполняет вызовы Posix и другие системные вызовы, такие как fork, exec и brk.

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

К числу других серверов относятся сетевой сервер, который содержит: полный стек TCP/IP; хранилище данных, простой сервер имен, который используют другие серверы; информационный сервер, который используется при отладке. Наконец, над серверным уровнем расположены пользовательские процессы. Единственное отличие между этой и другими системами Unix заключается в том, что библиотечные процедуры для чтения, записи и других системных вызовов выполняется посредством посылки сообщений серверам. За исключением данного отличия (скрытого в системных библиотеках) это обычные пользовательские процессы, которые могут использовать POSIX API.

Взаимодействия между процессами

Поскольку именно механизм взаимодействия между процессами (Interprocess Communication, IPC) позволяет всем процессам работать вместе, он критически важен в мультисерверной операционной системе. Однако так как все серверы и драйверы в Minix 3 выполняются как физически изолированные процессы, они не могут напрямую вызывать функции друг друга или совместно использовать структуры данных. Вместо этого Minix 3 поддерживает IPC за счет передачи сообщений фиксированной длины на так называемом принципе рандеву (когда и отправитель, и получатель готовы к обмену, система копирует сообщение непосредственно от отправителя к получателю). Кроме того, имеется механизм асинхронных уведомлений о событиях. События, которые не могут быть реализованы, в таблице процессов помечаются как отложенные.

Minix 3 элегантно объединяет прерывания с системой передачи сообщений. Обработчики прерываний используют механизм уведомлений для сигнализации о завершении ввода/вывода. Этот механизм позволяет обработчику устанавливать бит в битовой карте «отложенных прерываний», а затем продолжать работу без блокировки. Когда драйвер готов к получению прерывания, ядро преобразует его в обычное сообщение.

Характеристики надежности

Причин высокой надежности Minix 3 несколько. Во-первых, в ядре выполняется код размером не более 4 тыс. строк, поэтому, исходя из скромной оценки 6 ошибок на 1000 строк, общее число ошибок в ядре, скорее всего, около 24. Сравните это число с 15 тыс. ошибок в Linux и намного большим их количеством в Windows. Поскольку все драйверы устройств, за исключением часов, — это пользовательские процессы, никакой посторонний код никогда не будет работать в режиме ядра. Кроме того, небольшой размер ядра позволяет более эффективно проверить его корректность либо вручную, либо с помощью формальных методов.

Архитектура IPC в Minix 3 не требует поддержки очередей или буферизации сообщений, что избавляет от необходимости управления буфером в ядре. Более того, поскольку IPC — это мощная конструкция, IPC-возможности каждого сервера и драйвера строго ограничены. Для каждого процесса строго определены используемые примитивы IPC, доступные адресаты и уведомления о пользовательских событиях. Пользовательские процессы, например, могут взаимодействовать только по принципу рандеву или посылать сообщения только серверам Posix.

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

Драйверы и серверы в режиме пользователя не могут работать с привилегиями суперпользователя. Они не могут получать доступ к областям памяти, находящимся за пределами их собственных адресных пространств, за исключением вызовов ядра (проверку корректности которых выполняет ядро). Более того, битовые карты и диапазоны внутри таблицы процессов ядра управляют набором допустимых вызовов ядра, возможностей IPC и допустимых портов ввода/вывода для каждого процесса в отдельности. Например, ядро может не допустить, чтобы драйвер принтера записывал информацию в пользовательские адресные пространства, обращался к портам ввода/вывода диска или посылал сообщения аудиодрайверу. В традиционных монолитных системах любой драйвер может делать что угодно.

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

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

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

Параметры производительности

В течение десятилетий разработчики критиковали мультисерверные архитектуры, базирующиеся на принципе микроядер, за их более низкую по сравнению с монолитными архитектурами производительность. Однако различные проекты подтверждают, что модульная архитектура на самом деле может обеспечивать сравнимую производительность. Несмотря на тот факт, что Minix 3 не была оптимизирована по производительности, система работает достаточно быстро. Потери производительности, которые возникают из-за того, что драйверы работают в режиме пользователя, по сравнению с драйверами в режиме ядра составляют менее 10%, и система может создаваться, в том числе ядро, общие драйверы и все серверы (112 компиляций и 11 ссылок), менее чем за 6 с на машине с процессором Athlon/2,2 ГГц.

Тот факт, что мультисерверные архитектуры позволяют поддерживать достаточно надежную Unix-подобную среду при весьма небольших потерях производительности, делает такой подход практически приемлемым. Minix 3 для Pentium можно загрузить бесплатно на условиях лицензии Berkeley с сайта www.minix3.org. Сейчас разрабатываются версии для других архитектур и встроенных систем.

Защита на базе языка

Самый радикальный подход, что весьма неожиданно, предложили в Microsoft Research, отказавшись от операционной системы как единой программы, выполняющейся в режиме ядра, и некоторого набора пользовательских процессов, функционирующих в режиме пользователя. Вместо этого предлагается система, написанная на совершенно новых, обеспечивающих безопасность типов языках, которые избавлены от всех проблем с указателями и других ошибок, связанных с Си и C++. Как и предыдущие два подхода, этот подход был предложен несколько десятилетий назад и был реализован в компьютере Burroughs B5000. Тогда существовал только язык Алгол, и защита поддерживалась не с помощью MMU (которого вообще не было в машине), а благодаря тому, что компилятор Алгол просто не генерировал «опасный» код. Подход, предложенный Microsoft Research, адаптирует эту идею к условиям XXI века.

Общее описание

Эта система, получившая название Singularity, практически полностью написана на Sing#, новом языке, гарантирующим безопасность типов. Этот язык основан на C#, но дополнен примитивами передачи сообщений, семантика которых определяется формальными, описанными средствами языка контрактами. Поскольку язык жестко ограничивает системные и пользовательские процессы, все процессы могут работать вместе в едином виртуальном адресном пространстве. Это увеличивает как безопасность (поскольку компилятор не позволит одному процессу менять данные другого процесса), так и эффективность (поскольку это избавляет от перехватов вызовов ядра (kernel trap) и переключений контекста.

Более того, архитектура Singularity является гибкой, поскольку каждый процесс — это замкнутая сущность и поэтому она может иметь свой собственный код, структуры данных, структуру памяти, систему времени исполнения, библиотеки и сборщик мусора. MMU поддерживается, но он только распределяет страницы, а не устанавливает отдельный защищенный домен для каждого процесса.

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

Микроядро

Операционная система Singularity состоит из процесса микроядра и набора пользовательских процессов, которые обычно работают в общем виртуальном адресном пространстве. Микроядро контролирует доступ к аппаратному обеспечению, резервирует и освобождает память, создает, закрывает и планирует цепочки, поддерживает синхронизацию цепочек с помощью семафоров, поддерживает синхронизацию между процессами с помощью каналов, контролирует ввод/вывод. Каждый драйвер устройств работает как отдельный процесс.

Хотя большая часть микроядра написана на Sing#, отдельные компоненты созданы на C#, C++ или assembler и должны быть надежными, поскольку проверить их корректность невозможно. К надежному коду относятся уровень аппаратной абстракции и сборщик мусора. Уровень аппаратной абстракции скрывает низкоуровневое аппаратное обеспечение от системы, инкапсулируя такие концепции, как порты ввода/вывода, линии запросов на прерывания, каналы прямого доступа к памяти и таймеры для того, чтобы предоставить остальной части операционной системы интероперабельные абстракции.

Взаимодействие между процессами

Пользовательские процессы получают системные сервисы, посылая строго типизированные сообщения микроядру по двунаправленным каналам точка-точка. Фактически эти каналы используются для всех взаимодействий между процессами. В отличие от других систем передачи сообщений, имеющих библиотеку с функциями send и receive, Sing# полностью поддерживает каналы на уровне языка, в том числе формальные спецификации типизации и протоколов. Для того чтобы прояснить это, рассмотрим спецификацию канала.

contract C1 {

in message Request(int x) requires x > 0;

out message Reply(int y);

out message Error();

state Start:

Request? -> Pending;

state Pending: one {

Reply! -> Start;

Error! -> Stopped;

}

state Stopped: ;

}

Этот контракт утверждает, что канал принимает три сообщения: Request, Reply и Error. Первый имеет в качестве параметра положительное целое, второй — целое, а третий параметров не имеет. Когда для доступа к серверу используется канал, сообщения Request передаются от клиента к серверу, а другие два сообщения пересылаются иным путем. Машина состояний описывает протокол для канала.

В состоянии Start клиент посылает сообщение Request, переводя канал в состояние Pending. Сервер может в ответ послать либо сообщение Reply, либо сообщение Error. Сообщение Reply переводит канал обратно в состояние Start, в котором взаимодействие может продолжаться. Сообщение Error переводит канал в состояние Stopped, завершая взаимодействие по каналу.

Куча

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

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

Файловая система

Singularity поддерживает единое иерархическое пространство имен для всех сервисов. Корневой сервер имен использует вершину дерева, но другие серверы имен могут монтироваться на своих собственных узлах. В частности, файловая система, которая представляет собой всего лишь процесс, монтируется на /fs, поэтому, например, имя /fs/users/linda/foo может быть файлом пользователя. Файлы реализуются как B-деревья, в которых номера блоков служат ключами. Когда пользовательский процесс запрашивает файл, файловая система отдает драйверу диска команду поместить запрашиваемые блоки в кучу. Владение затем передается так, как описано выше.

Проверка

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

  • компилятор проверяет безопасность типов, владение объектами, протоколы каналов и так далее;
  • компилятор генерирует Microsoft Intermediate Language, переносимый JVM-подобный байт-код, который может проверять верификатор;
  • MSIL компилируется в код x86 для базового компьютера, который может добавлять в код проверки времени исполнения (однако существующий компилятор этого не делает).

Добиться более высокой надежности можно с помощью средств, позволяющих обнаружить ошибки в самих верификаторах.

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

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

Два других подхода заменяют унаследованные операционные системы на более надежные и защищенные. Мультисерверный подход предусматривает работу каждого драйвера и компонента операционной системы в отдельном пользовательском процессе и позволяет им взаимодействовать с помощью механизма IPC микроядра. Наконец, Singularity, самый радикальный подход, использует язык, обеспечивающий безопасность типов, единое адресное пространство и формальные контракты, которые строго ограничивают возможности каждого модуля.

Три из четырех исследовательских проектов — паравиртуализация на базе L4, Minix 3 и Singularity — используют микроядра. Пока не известно, какой из этих подходов в перспективе получит широкое распространение (если это не будет какое-то иное решение). Тем не менее интересно отметить, что микроядра, долгое время считавшиеся неприемлемыми из-за их более низкой производительности по сравнению с монолитными ядрами, могут снова вернуться в операционные системы из-за их потенциально более высокой надежности, что многие считают важнее производительности. Колесо истории повернулось.

Эндрю Таненбаум (ast@cs.vu.nl) — профессор информатики Vrije Universiteit (Амстердам, Голландия). Джоррит Хердер (jnherder@cs.vu.nl) — аспирант отделения компьютерных систем факультета информатики Vrije Universiteit. Хербер Бос (bos@cs.vu.nl)- доцент отделения компьютерных систем факультета информатики Vrije Universiteit.

Литература
  1. V. Basili, B. Perricone, Software Errors and Complexity: An Empirical Investigation, Comm. ACM, Jan. 1984.
  2. T. Ostrand, E. Weyuker, The Distribution of Faults in a Large Industrial Software System, Proc. Int?l Symp. Software Testing and Analysis, ACM Press, 2002.
  3. A. Chou et al., An Empirical Study of Operating System Errors, Proc. 18th ACM Symp. Operating System Principles, ACM Press, 2001.
  4. M. Swift, B. Bershad, H. Levy, Improving the Reliability of Commodity Operating Systems, ACM Trans. Computer Systems, vol. 23, 2005.
  5. M. Swift et al., Recovering Device Drivers, Proc. 6th Symp. Operating System Design and Implementation, ACM Press, 2003.
  6. R. Goldberg, Architecture of Virtual Machines, Proc. Workshop Virtual Computer Systems, ACM Press, 1973.
  7. J. LeVasseur et al., Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines, Proc. 6th Symp. Operating System Design and Implementation, 2004.
  8. J. Liedtke, On Microkernel Construction, Proc. 15th ACM Symp. Operating System Principles, ACM Press, 1995.
  9. H. Hartig et al., The Performance of Microkernel-Based Systems, Proc. 16th ACM Symp. Operating System Principles, ACM Press, 1997.
  10. J.N. Herder et al., Modular System Programming in MINIX 3, Usenix; www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf.

Andrew Tanenbaum, Jorrit Herder, Herbert Bos, Can We Make Operating Systems Reliable and Secure?, IEEE Computer, May, 2006. IEEE Computer Society, 2006, All rights reserved. Reprinted with permission.