Микроядро - Microkernel

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

В Информатика, а микроядро (часто сокращенно μ-ядро) - это почти минимальное количество программного обеспечения которые могут предоставить механизмы, необходимые для реализации Операционная система (ОПЕРАЦИОННЫЕ СИСТЕМЫ). Эти механизмы включают низкоуровневые адресное пространство управление, нить менеджмент и межпроцессного взаимодействия (МПК).

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

С точки зрения размера исходного кода микроядра часто меньше, чем монолитные ядра. В МИНИКС 3 микроядро, например, имеет всего около 12 000 строк кода.[2]

История

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

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

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

Те же механизмы, которые позволили распределить ядро ​​в пространстве пользователя, также позволили распределить систему по сетевым каналам. Первые микроядра, в частности Мах, оказался неутешительным по своим характеристикам, но присущие ему преимущества оказались настолько значительными, что это стало основным направлением исследований в конце 1990-х годов.[нужна цитата ] Однако за это время скорость компьютеров значительно выросла по сравнению с сетевыми системами, и недостатки в производительности стали преобладать над преимуществами с точки зрения разработки.[нужна цитата ] Было предпринято множество попыток адаптировать существующие системы для повышения производительности, но накладные расходы всегда были значительными, и большая часть этих усилий требовала переноса программ пользовательского пространства обратно в ядро. К 2000 году большинство крупномасштабных (похожих на Мах) усилий прекратились, хотя Apple macOS, выпущенный в 2001 году, использует гибридное ядро называется XNU, который сочетает в себе сильно модифицированный (гибридный) ОСФМК Ядро 7.3 с кодом из BSD UNIX,[10][11] и это ядро ​​также используется в iOS, tvOS, и watchOS. По состоянию на 2012 год, на основе Маха GNU Hurd также функциональна и включена в тестовые версии Arch Linux и Debian.

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

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

Вступление

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

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

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

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

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

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

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

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

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

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

Серверы

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

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

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

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

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

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

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

Необходимые компоненты и минимальность

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

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

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

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

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

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

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

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

Спектакль

На большинстве основных процессоров получение услуги в системе на основе микроядра по своей природе дороже, чем в монолитной системе.[12] В монолитной системе услуга предоставляется одним системным вызовом, для чего требуется два переключатели режимов (изменения процессора звенеть или же Режим CPU ). В системе на основе микроядра услуга достигается путем отправки сообщения IPC на сервер и получения результата в другом сообщении IPC от сервера. Это требует переключатель контекста если драйверы реализованы как процессы, или вызов функции, если они реализованы как процедуры. Кроме того, передача фактических данных на сервер и обратно может повлечь за собой дополнительные накладные расходы на копирование, в то время как в монолитной системе ядро ​​может напрямую обращаться к данным в буферах клиента.

Поэтому производительность является потенциальной проблемой в системах с микроядрами. Действительно, опыт использования микроядер первого поколения, таких как Мах и Припев показали, что системы на их основе работают очень плохо.[15] Тем не мение, Йохен Лидтке показали, что проблемы с производительностью Маха были результатом плохой разработки и реализации, в частности чрезмерного тайник след.[16]Лидтке продемонстрировал на собственном L4 микроядро что за счет тщательного проектирования и реализации, и особенно следуя принципу минимальности, затраты на IPC могут быть снижены более чем на порядок по сравнению с Mach. Производительность IPC L4 по-прежнему остается непревзойденной для ряда архитектур.[23][24][25]

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

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

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

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

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

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

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

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

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

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

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

Это привело к тому, что называется микроядра третьего поколения,[34]характеризуется ориентированным на безопасность API с доступом к ресурсам, контролируемым возможности, виртуализация как первоклассная проблема, новые подходы к управлению ресурсами ядра,[35]и цель дизайна - пригодность для формальный анализ, помимо обычной цели высокой производительности. Примеры Койотос, seL4, Нова,[36][37]Редокс и Fiasco.OC.[36][38]

В случае seL4 была достигнута полная формальная проверка реализации,[34] т.е. математическое доказательство того, что реализация ядра соответствует его формальной спецификации. Это обеспечивает гарантию того, что свойства, доказанные для API, действительно сохраняются для реального ядра, степень уверенности превышает даже CC EAL7. (Обратите внимание, что это все еще не 100% гарантия, поскольку все математические доказательства действительны настолько, насколько они достоверны, сами по себе не доказаны, аксиомы, и по-прежнему требуют реальной научной проверки на надежность. Видеть: Теорема Гёделя о неполноте За этим последовали доказательства свойств обеспечения безопасности API, а также доказательство, демонстрирующее, что исполняемый двоичный код является правильным переводом реализации C, выводя компилятор из TCB. Взятые вместе, эти доказательства обеспечивают сквозное доказательство свойств безопасности ядра.[39]

Наноядро

Период, термин наноядро или же пикоядро исторически упоминается:

  • Ядро, в котором общий объем кода ядра, то есть кода, выполняемого в привилегированном режиме оборудования, очень мал. Период, термин пикоядро иногда использовался, чтобы еще больше подчеркнуть малый размер. Период, термин наноядро был придуман Джонатаном С. Шапиро в газете Архитектура KeyKOS NanoKernel. Это был сардонический ответ на Мах, который утверждал, что является микроядром, в то время как Шапиро считал его монолитным, по существу неструктурированным и более медленным, чем системы, которые он стремился заменить. Последующее повторное использование этого термина и ответ на него, включая чеканку пикоядра, позволяют предположить, что суть была упущена. Обе наноядро и пикоядро впоследствии стали иметь то же значение, что и термин микроядро.
  • Слой виртуализации под операционной системой, который правильнее называть гипервизор.
  • А уровень аппаратной абстракции который формирует часть ядра самого низкого уровня, иногда используется для обеспечения в реальном времени функциональность обычных операционных систем, например Adeos.

Также есть по крайней мере один случай, когда термин наноядро используется для обозначения не маленького ядра, а того, которое поддерживает наносекунда разрешение часов.[40]

Смотрите также

Рекомендации

  1. ^ Гердер, Йоррит Н. (23 февраля 2005 г.). «К истинной операционной системе на микроядре» (PDF). minix3.org. Получено 22 июн 2015.
  2. ^ "прочитайте больше". Получено 20 декабря 2016.
  3. ^ "Лауреат премии Computer Pioneer Award 2002". IEEE Computer Society. Получено 13 сентября 2016.
  4. ^ Бринч Хансен, Пер (2004). История программиста: жизнь компьютерного пионера. Получено 13 сентября 2016.
  5. ^ Бринч Хансен, Пер (апрель 1969). Программное обеспечение RC 4000: система мультипрограммирования (PDF) (Технический отчет). Regnecentralen. Получено 13 сентября 2016.
  6. ^ Бринч Хансен, Пер (1970). «Ядро многопрограммной операционной системы» (PDF). Коммуникации ACM. 13 (4): 238–250. CiteSeerX  10.1.1.105.4204. Дои:10.1145/362258.362278. S2CID  9414037.
  7. ^ .Вульф, Уильям; Коэн, Эллис; Корвин, Уильям; Джонс, Анита; Левин, Рой; Pierson, C .; Поллак, Фред (июнь 1974). «HYDRA: ядро ​​многопроцессорной операционной системы». Коммуникации ACM. 17 (6): 337–345. Дои:10.1145/355616.364017. S2CID  8011765.
  8. ^ Рашид, Ричард; Робертсон, Джордж (декабрь 1981). Акцент: ядро ​​сетевой операционной системы, ориентированной на взаимодействие.. SOSP '81 Труды восьмого симпозиума ACM по принципам операционных систем. Пасифик Гроув, Калифорния, США. С. 64–75. Дои:10.1145/800216.806593.
  9. ^ Сассенрат, Карл (1986). Справочное руководство ядра Amiga ROM. Exec.
  10. ^ Джим Маги. WWDC 2000 Сессия 106 - Mac OS X: ядро. 14 минут в.
  11. ^ «Перенос приложений UNIX / Linux на Mac OS X». яблоко. Получено 26 апреля 2011.
  12. ^ а б c Лидтке, Йохен (сентябрь 1996 г.). «К реальным микроядрам». Коммуникации ACM. 39 (9): 70–77. Дои:10.1145/234215.234473. S2CID  2867357.
  13. ^ Хайзер, Гернот; Улиг, Фолькмар; Левассер, Джошуа (январь 2006 г.). "Правильно ли выполнены микроядра мониторов виртуальных машин?" (PDF). Обзор операционных систем ACM SIGOPS. ACM. 40 (1): 95–99. Дои:10.1145/1113361.1113363. S2CID  7414062.
  14. ^ Лидтке, Йохен (Декабрь 1993 г.). Улучшение IPC за счет дизайна ядра. 14-й симпозиум ACM по принципам операционных систем. Эшвилл, Северная Каролина, США. С. 175–88. CiteSeerX  10.1.1.40.1293.
  15. ^ а б Чен, Дж. Брэдли; Бершад, Брайан Н. (декабрь 1993 г.). Влияние структуры операционной системы на производительность системы памяти (PDF). SOSP '93 Труды четырнадцатого симпозиума ACM по принципам операционных систем. Эшвилл, Северная Каролина, США. С. 120–133. Дои:10.1145/168619.168629.
  16. ^ а б c Лидтке, Йохен (Декабрь 1995 г.). О конструкции µ-ядра. SOSP '95 Труды пятнадцатого симпозиума ACM по принципам операционных систем. Курорт Коппер Маунтин, Колорадо, США. С. 237–250. Дои:10.1145/224056.224075.
  17. ^ Эльфинстон, Кевин; Хайзер, Гернот (ноябрь 2013 г.). От L3 к seL4: что мы узнали за 20 лет использования микроядер L4?. SOSP '13 Материалы двадцать четвертого симпозиума ACM по принципам операционных систем. Фармингтон, Пенсильвания, США. С. 133–150. Дои:10.1145/2517349.2522720.
  18. ^ «Синхронная передача сообщений». Получено 14 июля 2019.
  19. ^ «Набор инструментов QNX High Availability Toolkit» (PDF). Архивировано из оригинал (PDF) 24 августа 2005 г.
  20. ^ Вонг, Уильям (27 апреля 2007 г.). «Ввод / вывод, ввод / вывод, мы готовы к виртуальной работе». Электронный дизайн. Получено 8 июн 2009.
  21. ^ Александр, Майкл Т. (1971). «Организация и особенности Терминальной системы Мичигана». Материалы осенней совместной компьютерной конференции 16–18 ноября 1971 г.. 40: 589–591. Дои:10.1145/1478873.1478951. S2CID  14614148.
  22. ^ Львов, Джон (1 августа 1977 г.). Комментарий Льва к 6-му изданию UNIX с исходным кодом. Одноранговые коммуникации. ISBN  978-1-57398-013-5.
  23. ^ Лидтке, Йохен; Эльфинстон, Кевин; Шенберг, Себастьян; Хертиг, Германн; Хайзер, Гернот; Ислам, Найим; Джегер, Трент (май 1997 г.). Достигнута производительность IPC (по-прежнему основа для расширяемости). 6-й семинар по актуальным темам в операционных системах. Кейп-Код, Массачусетс, США: IEEE. С. 28–31.
  24. ^ Грей, Чарльз; Чепмен, Мэтью; Чабб, Питер; Мосбергер-Танг, Дэвид; Хайзер, Гернот (Апрель 2005 г.). Itanium - сказка разработчика систем. Ежегодная техническая конференция USENIX. Аннахайм, Калифорния, США. С. 264–278.
  25. ^ ван Шайк, Карл; Хайзер, Гернот (Январь 2007 г.). Высокопроизводительные микроядра и виртуализация на ARM и сегментированных архитектурах. 1-й международный семинар по микроядрам для встраиваемых систем. Сидней, Австралия: НИКТА. С. 11–21. Архивировано из оригинал 26 апреля 2007 г.. Получено 1 апреля 2007.
  26. ^ Хертиг, Германн; Хохмут, Майкл; Лидтке, Йохен; Шенберг, Себастьян (октябрь 1997 г.). «Производительность систем на основе µ-ядра». Материалы шестнадцатого симпозиума ACM по принципам операционных систем: 66–77. Дои:10.1145/268998.266660. ISBN  0-89791-916-5. S2CID  1706253.
  27. ^ Гефло, Ален; Джегер, Трент; Пак, Юнхо; Лидтке, Йохен; Эльфинстон, Кевин Дж .; Улиг, Фолькмар; Тидсуэлл, Джонатон Э .; Деллер, Люк; и другие. (2000). Многосерверный подход лесопилки. 9-й Европейский семинар ACM SIGOPS. Колдинг, Дания. С. 109–114. CiteSeerX  10.1.1.25.8376.
  28. ^ Лесли, Бен; Чабб, Питер; Фитцрой-Дейл, Николас; Гётц, Стефан; Грей, Чарльз; Макферсон, Люк; Поттс, Дэниел; Шен, Ютинг; Эльфинстон, Кевин; Хайзер, Гернот (Сентябрь 2005 г.). «Драйверы устройств пользовательского уровня: достигнутая производительность». Журнал компьютерных наук и технологий. 20 (5): 654–664. Дои:10.1007 / s11390-005-0654-4. S2CID  1121537.
  29. ^ Таненбаум, Эндрю С. "Дебаты Таненбаума-Торвальдса, часть II".
  30. ^ Таненбаум А., Гердер Дж. И Бос Х. (май 2006 г.).
  31. ^ Биггс, Саймон; Ли, Дэймон; Хайзер, Гернот (2018). «Жюри такое: дизайн монолитной ОС ошибочен: конструкции на основе микроядра повышают безопасность». Материалы 9-го Азиатско-Тихоокеанского семинара по системам. Остров Чеджу, Республика Корея: Ассоциация вычислительной техники. С. 1–7. Дои:10.1145/3265723.3265733.
  32. ^ Шапиро, Джонатан С .; Вебер, Сэмюэл. Проверка механизма удержания EROS. Конференция IEEE по безопасности и конфиденциальности. Архивировано из оригинал 3 марта 2016 г.
  33. ^ Элькадуве, Дхаммика; Кляйн, Гервин; Эльфинстон, Кевин (2007). Проверенная модель защиты микроядра seL4. отправлено для публикации.
  34. ^ а б Кляйн, Гервин; Эльфинстон, Кевин; Хайзер, Гернот; Андроник, июнь; Петух, Дэвид; Деррин, Филип; Элькадуве, Дхаммика; Энгельгардт, Кай; Колански, Рафаль; Норриш, Майкл; Сьюэлл, Томас; Туч, Харви; Уинвуд, Саймон (октябрь 2009 г.). seL4: формальная проверка ядра ОС (PDF). 22-й симпозиум ACM по принципам операционных систем. Big Sky, MT, США.
  35. ^ Элькадуве, Дхаммика; Деррин, Филип; Эльфинстон, Кевин (апрель 2008 г.). Дизайн ядра для изоляции и обеспечения физической памяти. 1-й семинар по изоляции и интеграции во встроенных системах. Глазго, Великобритания. Дои:10.1145/1435458. Архивировано из оригинал 24 апреля 2010 г.. Получено 17 августа 2009.
  36. ^ а б "TUD Home: Операционные системы: Исследование: Микроядро и гипервизор". Факультет компьютерных наук. Technische Universität Dresden. 12 августа 2010 г.. Получено 5 ноября 2011.
  37. ^ Стейнберг, Удо; Кауэр, Бернхард (апрель 2010 г.). NOVA: Архитектура безопасной виртуализации на основе микрогипервизора. Eurosys 2010. Париж, Франция. С. 209–222. Дои:10.1145/1755913.1755935.
  38. ^ Lackorzynski, Адам; Варг, Александр (март 2009 г.). Подсистемы укрощения - возможности универсального контроля доступа к ресурсам в L4. IIES'09: Второй семинар по изоляции и интеграции во встроенных системах. Нюрнберг, Германия. CiteSeerX  10.1.1.629.9845.
  39. ^ Кляйн, Гервин; Андроник, июнь; Эльфинстон, Кевин; Мюррей, Тоби; Сьюэлл, Томас; Колански, Рафаль; Хайзер, Гернот (февраль 2014 г.). «Комплексная формальная проверка микроядра ОС». ACM-транзакции в компьютерных системах. 32 (1): 2:1–2:70. Дои:10.1145/2560537. S2CID  4474342.
  40. ^ Дэвид Л. Миллс и Пол-Хеннинг Камп (28 ноября 2000 г.). «Наноядро» (PDF). Получено 28 августа 2017.

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