Микроядро

Структура монолитных и микроядерных операционных систем соответственно

В информатике микроядро операционной (часто сокращенно μ-ядро ) — это почти минимальный объем программного обеспечения , который может обеспечить механизмы, необходимые для реализации системы (ОС). Эти механизмы включают низкоуровневое управление адресным пространством , управление потоками и межпроцессное взаимодействие (IPC).

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

С точки зрения размера исходного кода микроядра часто меньше монолитных ядер . кода . Например, микроядро MINIX 3 содержит всего около 12 000 строк

История

Микроядра берут свое начало от датского пионера компьютеров Пера Бринча Хансена и его работы в датской компьютерной компании Regnecentralen , где он руководил разработкой программного обеспечения для компьютера RC 4000. В 1967 году компания Regnecentralen устанавливала прототип RC 4000 на заводе удобрений Zakłady Azotowe Puławy в Польше. В компьютере использовалась небольшая операционная система реального времени, адаптированная для нужд завода. Бринч Хансен и его команда были обеспокоены отсутствием универсальности и возможности повторного использования системы RC 4000. Они опасались, что для каждой установки потребуется другая операционная система, поэтому начали исследовать новые и более общие способы создания программного обеспечения для RC 4000. В 1969 году их усилия привели к созданию мультипрограммной системы RC 4000 . Его ядро ​​обеспечивало межпроцессное взаимодействие на основе передачи сообщений для 23 непривилегированных процессов, из которых 8 одновременно были защищены друг от друга. Кроме того, в нем реализовано планирование временных интервалов программ, выполняемых параллельно, инициирование и контроль выполнения программ по запросу других запущенных программ, а также инициирование передачи данных на периферийные устройства или с них. Помимо этих элементарных механизмов, у него не было встроенной стратегии выполнения программы и распределения ресурсов. Эта стратегия должна была быть реализована посредством иерархии запущенных программ, в которой родительские процессы имели полный контроль над дочерними процессами и выступали в качестве их операционных систем.

Следуя работе Бринча Хансена, микроядра разрабатываются с 1970-х годов. Сам термин микроядро впервые появился не позднее 1981 года. Микроядра были задуманы как ответ на изменения в компьютерном мире и на ряд проблем, связанных с адаптацией существующих « моноядер » к этим новым системам. Постоянно разрабатывались новые драйверы устройств, стеки протоколов, файловые системы и другие низкоуровневые системы. Этот код обычно располагался в монолитном ядре и поэтому требовал значительной работы и тщательного управления кодом. Микроядра были разработаны с идеей, что все эти сервисы будут реализованы как программы пользовательского пространства, как и любые другие, что позволит работать с ними монолитно, запускать и останавливать их, как любую другую программу. Это не только облегчит работу с этими сервисами, но и позволит разделить код ядра, чтобы его можно было точно настроить, не беспокоясь о непредвиденных побочных эффектах. Более того, это позволит «строить» совершенно новые операционные системы на общем ядре, что будет способствовать исследованию ОС.

первые пригодные для использования локальные сети . Микроядра были очень горячей темой в 1980-х годах, когда были представлены . Ядро AmigaOS Exec было ранним примером, представленным в 1986 году и использовавшимся на ПК с относительным коммерческим успехом. Отсутствие защиты памяти, которое в других отношениях считается недостатком, позволило этому ядру иметь очень высокую производительность передачи сообщений, поскольку ему не нужно было копировать данные при обмене сообщениями между программами пользовательского пространства.

Те же механизмы, которые позволяли распространять ядро ​​в пользовательском пространстве, также позволяли распространять систему по сетевым каналам. Первые микроядра, особенно Mach , созданные Ричардом Рашидом , показали неутешительные результаты, но присущие им преимущества оказались настолько значительными, что это стало основным направлением исследований в конце 1990-х годов. Однако за это время скорость компьютеров значительно выросла по сравнению с сетевыми системами, и недостатки в производительности стали подавлять преимущества с точки зрения разработки.

Было предпринято множество попыток адаптировать существующие системы для повышения производительности, но накладные расходы всегда были значительными, и большинство этих усилий требовало перемещения программ пользовательского пространства обратно в ядро. К 2000 году большинство крупномасштабных усилий по созданию ядра Mach завершилось, хотя macOS Apple , выпущенная в 2001 году, по-прежнему использует гибридное ядро ​​под названием XNU , которое сочетает в себе сильно модифицированное (гибридное) OSF/1 ядро ядро ​​Mach ( OSFMK 7.3) с код из BSD UNIX, и это ядро ​​также используется в iOS , tvOS и watchOS . Windows NT , начиная с NT 3.1 и продолжая Windows 11 , использует гибридную конструкцию ядра. По состоянию на 2012 год на базе Mach GNU Hurd также функционален и включен в тестовые версии Arch Linux и Debian .

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

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

Введение

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

Распространение программного обеспечения Беркли (BSD) Unix положило начало эпохе более крупных ядер. В дополнение к базовой системе, состоящей из процессора, дисков и принтеров, BSD добавила полную сетевую систему TCP/IP и ряд «виртуальных» устройств, которые позволяли существующим программам работать «невидимо» по сети. Этот рост продолжался в течение многих лет, в результате чего появились ядра с миллионами строк исходного кода . В результате такого роста ядра стали подвержены ошибкам, и их становилось все труднее поддерживать.

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

Межпроцессное взаимодействие

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

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

Микроядра первого поколения обычно поддерживали как синхронный, так и асинхронный IPC и страдали от низкой производительности IPC. Йохен Лидтке предположил, что основной причиной таких плохих показателей является разработка и внедрение механизмов IPC. В своем микроядре L4 он впервые применил методы, которые на порядок снизили затраты на IPC . К ним относятся системный вызов IPC, который поддерживает операции отправки и получения, делая все IPC синхронными и передавая в регистры как можно больше данных. Кроме того, Лидтке представил концепцию прямого переключения процесса , при которой во время выполнения IPC выполняется (неполное) переключение контекста от отправителя непосредственно к получателю. Если, как в L4, часть или все сообщение передается в регистрах, при этом регистровая часть сообщения передается без какого-либо копирования. Более того, избегаются накладные расходы на вызов планировщика; это особенно полезно в обычном случае, когда IPC используется в виде удаленного вызова процедур (RPC) клиентом, вызывающим сервер. Другая оптимизация, называемая отложенным планированием , позволяет избежать обхода очередей планирования во время IPC, оставляя потоки, которые блокируются во время IPC, в очереди готовности. После вызова планировщика он перемещает такие потоки в соответствующую очередь ожидания. Поскольку во многих случаях поток разблокируется перед следующим вызовом планировщика, этот подход экономит значительную работу. Подобные подходы с тех пор были приняты QNX и МИНИКС 3 .

В серии экспериментов Чен и Бершад сравнили количество циклов памяти на инструкцию (MCPI) монолитного Ultrix с циклами микроядра Mach в сочетании с сервером 4.3BSD Unix- , работающим в пользовательском пространстве . Их результаты объяснили более низкую производительность Mach из-за более высокого MCPI и продемонстрировали, что IPC сам по себе не несет ответственности за большую часть накладных расходов системы, что позволяет предположить, что оптимизации, ориентированные исключительно на IPC, будут иметь ограниченный эффект. Позже Лидтке уточнил результаты Чена и Бершада, отметив, что большая часть различий между Ultrix и Mach MCPI была вызвана промахами кэша емкости , и пришел к выводу, что резкое сокращение рабочего набора кэша микроядра решит проблему.

В системе клиент-сервер большая часть связи по существу синхронна, даже если используются асинхронные примитивы, поскольку типичной операцией является клиент, вызывающий сервер и затем ожидающий ответа. Поскольку он также обеспечивает более эффективную реализацию, большинство микроядер обычно следовали примеру L4 и предоставляли только синхронный примитив IPC. Асинхронный IPC можно реализовать поверх, используя вспомогательные потоки. Однако опыт показал, что полезность синхронного IPC сомнительна: синхронный IPC навязывает многопоточный дизайн простым в остальном системам, что приводит к усложнению синхронизации. Более того, вызов сервера, подобный RPC, упорядочивает клиент и сервер, чего следует избегать, если они работают на разных ядрах. Поэтому версии L4, развернутые в коммерческих продуктах, сочли необходимым добавить механизм асинхронных уведомлений для лучшей поддержки асинхронной связи. Этот сигнальный механизм не передает данные и поэтому не требует буферизации ядром. Имея две формы IPC, они, тем не менее, нарушили принцип минимальности. Другие версии L4 полностью перешли на асинхронный IPC.

Поскольку синхронный IPC блокирует первую сторону до тех пор, пока другая не будет готова, неограниченное использование может легко привести к тупиковой ситуации. Более того, клиент может легко организовать атаку типа «отказ в обслуживании» на сервере, отправив запрос и даже не попытавшись получить ответ. Следовательно, синхронный IPC должен обеспечивать средства предотвращения бессрочной блокировки. Многие микроядра предоставляют таймауты для вызовов IPC, которые ограничивают время блокировки. На практике выбрать разумные значения таймаутов сложно, и системы почти неизбежно используют бесконечные таймауты для клиентов и нулевые таймауты для серверов. Как следствие, наблюдается тенденция к тому, чтобы не предоставлять произвольные тайм-ауты, а только флаг, который указывает, что IPC должен немедленно выйти из строя, если партнер не готов. Этот подход эффективно обеспечивает выбор двух значений таймаута: нуля и бесконечности. Последние версии L4 и MINIX пошли по этому пути (более старые версии L4 использовали таймауты). QNX позволяет избежать этой проблемы, требуя от клиента указать буфер ответа как часть вызова отправки сообщения. Когда сервер отвечает, ядро ​​копирует данные в буфер клиента, не дожидаясь явного получения клиентом ответа.

Серверы

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

Базовый набор серверов для микроядра общего назначения включает серверы файловой системы, серверы драйверов устройств, сетевые серверы, серверы отображения и серверы устройств пользовательского интерфейса. Этот набор серверов (взятый из QNX ) предоставляет примерно тот же набор сервисов, который предлагает монолитное ядро ​​Unix . Необходимые серверы запускаются при запуске системы и предоставляют обычным прикладным программам такие услуги, как доступ к файлам, сети и устройствам. Когда такие серверы работают в среде пользовательского приложения, разработка сервера аналогична разработке обычного приложения, а не процессу сборки и загрузки, необходимому для разработки ядра.

Кроме того, многие «сбои» можно исправить, просто остановив и перезапустив сервер . Однако часть состояния системы теряется при выходе из строя сервера, поэтому этот подход требует, чтобы приложения справлялись с сбоем. Хорошим примером является сервер, отвечающий за TCP/IP- соединения: если этот сервер перезапустить, приложения потеряют соединение, что является нормальным явлением в сетевой системе. Для других служб сбой менее ожидаем и может потребовать внесения изменений в код приложения. Для QNX возможность перезапуска предлагается в виде QNX High Availability Toolkit.

Драйверы устройств

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

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

Драйверы пользовательского режима на самом деле появились раньше микроядер. Терминальная система штата Мичиган (MTS) в 1967 году поддерживала драйверы пользовательского пространства (включая поддержку файловой системы), став первой операционной системой, разработанной с такой возможностью. Исторически сложилось так, что драйверы представляли меньшую проблему, поскольку количество устройств было небольшим и в любом случае заслуживало доверия, поэтому их наличие в ядре упрощало проект и позволяло избежать потенциальных проблем с производительностью. Это привело к традиционному стилю Unix «драйвер в ядре», Linux и Windows NT. С распространением различного рода периферийных устройств объем кода драйверов увеличился, и в современных операционных системах размер кода доминирует над ядром.

Основные компоненты и минимализм

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

• Некоторые механизмы работы с адресными пространствами , необходимые для управления защитой памяти
• Некоторая абстракция выполнения для управления распределением ЦП, обычно потоки или активации планировщика.
• Межпроцессное взаимодействие , необходимое для вызова серверов, работающих в их собственных адресных пространствах.

Этот минималистичный дизайн был впервые предложен компанией Бринча Хансена и Nucleus IBM гипервизором виртуальной машины . Лидтке С тех пор он был формализован в принципе минимальности :

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

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

С принципом минимальности связано и не менее важно для проектирования микроядра разделение механизма и политики . Это то, что позволяет создавать произвольные системы поверх минимального ядра. Любая политика, встроенная в ядро, не может быть перезаписана на уровне пользователя и, следовательно, ограничивает универсальность микроядра. Политику, реализованную на серверах уровня пользователя, можно изменить, заменив серверы (или позволив приложению выбирать между конкурирующими серверами, предлагающими аналогичные услуги).

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

Для запуска ( загрузки ) системы на основе микроядра требуются драйверы устройств , которые не являются частью ядра. Обычно это означает, что они упакованы вместе с ядром в загрузочный образ, и ядро ​​поддерживает протокол начальной загрузки, который определяет, как находятся и запускаются драйверы; это традиционная процедура начальной загрузки микроядер L4 . Некоторые микроядра упрощают это, помещая некоторые ключевые драйверы внутри ядра (в нарушение принципа минимальности), LynxOS и оригинальный Minix примерами являются . Некоторые даже включают ​​файловую систему в ядро для упрощения загрузки. Система на основе микроядра может загружаться через мультизагрузочный загрузчик. Такие системы обычно загружают статически связанные серверы для начальной загрузки или монтируют образ ОС для продолжения загрузки.

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

Производительность

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

Таким образом, производительность является потенциальной проблемой в системах микроядра. Опыт микроядер первого поколения, таких как Mach и ChorusOS, показал, что системы на их основе работают очень плохо. Однако Йохен Лидтке показал, что проблемы с производительностью Маха были результатом плохого проектирования и реализации, в частности, чрезмерного использования кэша Маха . Лидтке продемонстрировал на своем собственном микроядре L4 , что благодаря тщательному проектированию и реализации, и особенно следованию принципу минимальности, затраты на IPC можно снизить более чем на порядок по сравнению с Mach. Производительность IPC L4 по-прежнему остается непревзойденной во многих архитектурах.

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

Существует ряд коммерческих мультисерверных систем, в частности системы реального времени QNX и Integrity . Для этих многосерверных систем не было опубликовано всестороннего сравнения производительности по сравнению с монолитными системами. Более того, производительность, похоже, не является первостепенной проблемой для тех коммерческих систем, которые вместо этого делают упор на надежное быстрое время отклика на обработку прерываний (QNX) и простоту ради надежности. Попыткой создания высокопроизводительной многосерверной операционной системы стал проект IBM Sawmill Linux. Однако этот проект так и не был завершен.

Тем временем было показано, что драйверы устройств пользовательского уровня могут приблизиться к производительности встроенных в ядро ​​драйверов даже для таких высокопроизводительных устройств с высоким уровнем прерываний, как Gigabit Ethernet. Кажется, это означает, что возможны высокопроизводительные многосерверные системы.

Безопасность

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

Следовательно, конструкции микроядра использовались для систем, предназначенных для приложений с высоким уровнем безопасности, включая KeyKOS , EROS и военные системы. Фактически, общие критерии (CC) на самом высоком уровне доверия ( Уровень обеспечения оценки (EAL) 7) имеют явное требование, чтобы цель оценки была «простой», что является признанием практической невозможности установления истинной надежности сложной системы. Опять же, термин «простой» вводит в заблуждение и нечетко определен. По крайней мере, Критерии оценки доверенных компьютерных систем Министерства обороны ввели несколько более точную формулировку на курсах B3/A1:

«TCB должен [реализовать] законченные, концептуально простые механизмы защиты с точно определенной семантикой. Значительное системное проектирование должно быть направлено на минимизацию сложности TCB, а также на исключение из TCB тех модулей, которые не являются критически важными для защиты».

- Критерии оценки надежности компьютерной системы Министерства обороны

В 2018 году в документе, представленном на Азиатско-Тихоокеанской системной конференции, утверждалось, что микроядра явно безопаснее, чем монолитные ядра, путем исследования всех опубликованных критических CVE для ядра Linux на тот момент . Исследование пришло к выводу, что 40% проблем вообще не могут возникнуть в формально проверенном микроядре, и только 4% проблем останутся полностью неустраненными в такой системе.

Третье поколение

Более поздние работы над микроядрами были сосредоточены на формальных спецификациях API ядра и формальных доказательствах свойств безопасности API и правильности реализации. Первым примером этого является математическое доказательство механизмов ограничения в EROS, основанное на упрощенной модели API EROS. Совсем недавно (в 2007 году) был выполнен полный набор машинных проверок свойств модели защиты seL4 , версии L4.

Это привело к появлению так называемых микроядер третьего поколения . характеризуется ориентированным на безопасность API с доступом к ресурсам, контролируемым возможностями , виртуализацией как первоклассной задачей, новыми подходами к управлению ресурсами ядра, и цель разработки — пригодность для формального анализа , помимо обычной цели — высокой производительности. Примеры: Coyotos , seL4 , Nova, Redox и Fiasco.OC.

В случае seL4 достигнута полная формальная проверка реализации, т.е. математическое доказательство того, что реализация ядра соответствует его формальной спецификации. Это обеспечивает гарантию того, что свойства, подтвержденные в отношении API, действительно сохраняются для реального ядра, степень уверенности, превосходящая даже CC EAL7. За этим последовали доказательства свойств API по обеспечению безопасности, а также доказательство, демонстрирующее, что исполняемый двоичный код является правильным переводом реализации C, исключающим компилятор из TCB. В совокупности эти доказательства представляют собой сквозное доказательство свойств безопасности ядра.

Примеры

Некоторые примеры микроядер:

• Амеба ОС
• Блэкберри QNX
• Генод
• HarmonyOS ( HarmonyOS NEXT )
• ХеленОС
• Горизонт
• L4 Семейство микроядер
• Мах
• Миникс
• Мидори
• Редокс
• Циркон
• Фантомная ОС

Наноядро

Термин «наноядро» или «пикоядро» исторически относился к:

• Ядро, в котором общий объем кода ядра, т. е. кода, выполняющегося в привилегированном режиме оборудования, очень мал. Термин «пикоядро» иногда использовался, чтобы еще больше подчеркнуть небольшой размер. Термин «наноядро» был придуман Джонатаном С. Шапиро в статье The KeyKOS NanoKernel Architecture . Это был сардонический ответ на Mach , который претендовал на роль микроядра, в то время как Шапиро считал его монолитным, по существу неструктурированным и более медленным, чем системы, которые он стремился заменить. Последующее повторное использование этого термина и реакция на него, включая чеканку пикоядра, позволяют предположить, что этот момент в значительной степени был упущен. И наноядро , и пикоядро впоследствии стали иметь одно и то же значение, выраженное термином микроядро.
• Уровень виртуализации под операционной системой, который правильнее называть гипервизором .
• Уровень аппаратной абстракции , образующий часть ядра самого низкого уровня, иногда используемый для обеспечения функциональности в реальном времени обычным операционным системам, таким как Adeos .

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

См. также

• Ядро (операционная система)
  • Экзоядро
  • Гибридное ядро
  • Загружаемый модуль ядра
  • Монолитное ядро
• Микросервисы
• Дебаты Таненбаума и Торвальдса
• Надежная вычислительная база
• Юникернел
• Мультисреда в режиме реального времени

Дальнейшее чтение

• Научные статьи о микроядрах (на CiteSeerX ), в том числе:
  • Дэн Хильдебранд (1992). «Архитектурный обзор QNX». Материалы семинара по микроядрам и другим ядерным архитектурам . стр. 113–126. CiteSeerX   10.1.1.459.4481 . ISBN  1-880446-42-1 . – базовый справочник QNX.
  • Таненбаум А., Гердер Дж. и Бос Х. (май 2006 г.). «Можем ли мы сделать операционные системы надежными и безопасными?» . Компьютер . 39 (5): 44–51. дои : 10.1109/MC.2006.156 . S2CID   99779 . Архивировано из оригинала 21 июня 2017 года . Проверено 3 апреля 2020 г. {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка ) - основной надежный справочник.
  • Блэк, Д.Л., Голуб, Д.Б., Жулин, Д.П., Рашид, Р.Ф., Дравс, Р.П., Дин, Р.В., Форин, А., Баррера, Дж., Токуда, Х., Малан, Г. и Бохман, Д. ( март 1992 г.). «Архитектура микроядерной операционной системы и Mach». Журнал обработки информации . 14 (4). {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка ) – основной справочник Маха.
• * Вархол, Питер Д. (январь 1994 г.). «Маленькие ядра добились больших успехов» . Байт . Архивировано из оригинала 7 марта 2006 года . Проверено 20 сентября 2017 г. Оценка нынешнего и будущего состояния микроядерных операционных систем по состоянию на январь 1994 г.
• Страница MicroKernel из репозитория шаблонов Портленда
• Дебаты Таненбаума и Торвальдса
  • Дебаты Таненбаума и Торвальдса, 1992.01.29
  • Таненбаум А.С. « Можем ли мы сделать операционные системы надежными и безопасными? ».
  • Торвальдс, Л. Линус Торвальдс снова о микроядрах, 2006.05.09
  • Шапиро, Дж. « Разоблачение последних достижений Линуса ».
  • Таненбаум, А.С. « Дебаты Таненбаума-Торвальдса: Часть II ».