Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

С точки зрения размера исходного кода микроядра часто меньше монолитных ядер . MINIX 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]

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

Было предпринято множество попыток адаптировать существующие системы для повышения производительности, но накладные расходы всегда были значительными, и большая часть этих усилий требовала переноса программ пользовательского пространства обратно в ядро. К 2000 году , наиболее крупные Mach усилие ядра закончилось, хотя Apple, MacOS , выпущенной в 2001 году, до сих пор использует гибридное ядро под названием XNU , который сочетает в себе сильно модифицированный (гибрид) OSF / 1 «s Mach ядро ( OSFMK 7,3 ядро) с код из BSD UNIX, [10] [11], и это ядро ​​также используется в iOS , tvOS и watchOS .Microsoft Windows NT 3.1, NT 3.5, NT 3.51, NT 4.0, 2000, XP, Vista, 7, 8, 8.1 и 10 до сих пор использовали гибридное ядро ​​на базе Mach. С 2012 года GNU Hurd на базе Mach также функционирует и включен в тестовые версии Arch Linux и Debian .

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

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

Введение [ править ]

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

Распределение Berkeley Software (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 и MINIX 3 . [ необходима цитата ]

В серии экспериментов Чен и Бершад сравнили количество циклов памяти на инструкцию (MCPI) монолитного Ultrix и микроядра Mach в сочетании с сервером 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] Это также позволяет не доверять драйверам пользовательского режима.

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

Основные компоненты и минимальность [ править ]

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

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

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

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

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

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

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

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

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

Производительность [ править ]

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

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

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

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

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

Безопасность [ править ]

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

Следовательно, конструкции микроядра использовались для систем, разработанных для приложений с высоким уровнем безопасности, включая KeyKOS , EROS и военные системы. Фактически, общие критерии (CC) на самом высоком уровне доверия ( Evaluation Assurance Level (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] и цель дизайна - пригодность для формального анализа , помимо обычной цели высокой производительности. Примеры: Coyotos , seL4 , Nova, [36] [37] Redox и Fiasco.OC. [36] [38]

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

Наноядро [ править ]

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

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

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

См. Также [ править ]

  • Ядро (информатика)
    • Exokernel
    • Гибридное ядро
    • Загружаемый модуль ядра
    • Монолитное ядро
  • Микросервисы
  • Дебаты Таненбаума-Торвальдса
  • Надежная вычислительная база
  • Unikernel
  • Мульти-окружающая среда в реальном времени

Ссылки [ править ]

  1. ↑ Гердер, Йоррит Н. (23 февраля 2005 г.). «К истинной операционной системе на микроядре» (PDF) . minix3.org . Проверено 22 июня 2015 года .
  2. ^ "читать дальше" . Проверено 20 декабря +2016 .
  3. ^ "Лауреат премии Computer Pioneer 2002" . Компьютерное общество IEEE . Проверено 13 сентября 2016 года .
  4. ^ Бринч Хансен, Пер (2004). История программиста: жизнь компьютерного пионера . Проверено 13 сентября 2016 года .
  5. ^ Бринч Хансен, Per (апрель 1969). Программное обеспечение RC 4000: Система мультипрограммирования (PDF) (Технический отчет). Regnecentralen . Проверено 13 сентября 2016 года .
  6. ^ Бринч Хансен, Пер (1970). «Ядро многопрограммной операционной системы» (PDF) . Коммуникации ACM . 13 (4): 238–250. CiteSeerX 10.1.1.105.4204 . DOI : 10.1145 / 362258.362278 . S2CID 9414037 .   
  7. ^ . Вульф, Уильям; Коэн, Эллис; Корвин, Уильям; Джонс, Анита; Левин, Рой; Pierson, C .; Поллак, Фред (июнь 1974). «HYDRA: ядро ​​многопроцессорной операционной системы». Коммуникации ACM . 17 (6): 337–345. DOI : 10.1145 / 355616.364017 . S2CID 8011765 . 
  8. ^ Рашид, Ричард; Робертсон, Джордж (декабрь 1981). Акцент: ядро ​​сетевой операционной системы, ориентированной на коммуникацию . SOSP '81 Труды восьмого симпозиума ACM по принципам операционных систем. Пасифик Гроув, Калифорния, США. С. 64–75. DOI : 10.1145 / 800216.806593 .
  9. ^ Сассенрат, Карл (1986). Справочное руководство Amiga ROM Kernel . Exec.
  10. ^ Джим Маги. WWDC 2000 Сессия 106 - Mac OS X: ядро . 14 минут в.
  11. ^ «Перенос приложений UNIX / Linux на Mac OS X» . Apple . Проверено 26 апреля 2011 года .
  12. ^ a b c Лидтке, Йохен (сентябрь 1996 г.). «К реальным микроядрам». Коммуникации ACM . 39 (9): 70–77. DOI : 10.1145 / 234215.234473 . S2CID 2867357 . 
  13. ^ Хайзер, Гернот ; Улиг, Фолькмар; Левассер, Джошуа (январь 2006 г.). "Правильно ли выполнены микроядра мониторов виртуальных машин?" . Обзор операционных систем ACM SIGOPS . ACM. 40 (1): 95–99. DOI : 10.1145 / 1113361.1113363 . S2CID 7414062 . 
  14. ^ Liedtke, Jochen (декабрь 1993). Улучшение IPC за счет дизайна ядра . 14-й симпозиум ACM по принципам операционных систем. Эшвилл, Северная Каролина, США. С. 175–88. CiteSeerX 10.1.1.40.1293 . 
  15. ^ а б Чен, Дж. Брэдли; Бершад, Брайан Н. (декабрь 1993 г.). Влияние структуры операционной системы на производительность системы памяти (PDF) . SOSP '93 Труды четырнадцатого симпозиума ACM по принципам операционных систем. Эшвилл, Северная Каролина, США. С. 120–133. DOI : 10.1145 / 168619.168629 .
  16. ^ a b c Лидтке, Йохен (декабрь 1995 г.). О построении µ-ядра . SOSP '95 Труды пятнадцатого симпозиума ACM по принципам операционных систем. Курорт Коппер Маунтин, Колорадо, США. С. 237–250. DOI : 10.1145 / 224056.224075 .
  17. ^ Эльфинстон, Кевин; Хайзер, Гернот (ноябрь 2013 г.). От L3 к seL4: что мы узнали за 20 лет использования микроядер L4? . SOSP '13 Материалы двадцать четвертого симпозиума ACM по принципам операционных систем. Фармингтон, Пенсильвания, США. С. 133–150. DOI : 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 года, Fall Joint Computer конференции . 40 : 589–591. DOI : 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. ^ Härtig, Hermann; Хохмут, Майкл; Лидтке, Йохен ; Шенберг, Себастьян (октябрь 1997 г.). «Производительность систем на основе µ-ядра» . Труды шестнадцатого симпозиума ACM по принципам операционных систем : 66–77. DOI : 10.1145 / 268998.266660 . ISBN 0-89791-916-5. S2CID  1706253 .
  27. ^ Gefflaut, Ален; Джегер, Трент; Пак, Юнхо; Лидтке, Йохен ; Эльфинстон, Кевин Дж .; Улиг, Фолькмар; Tidswell, Jonathon E .; Деллер, Люк; и другие. (2000). Многосерверный подход Лесопилки . 9-й Европейский семинар ACM SIGOPS. Колдинг, Дания. С. 109–114. CiteSeerX 10.1.1.25.8376 . 
  28. ^ Лесли, Бен; Чабб, Питер; Фитцрой-Дейл, Николас; Гётц, Стефан; Грей, Чарльз; Макферсон, Люк; Поттс, Дэниел; Шен, Ютинг; Эльфинстон, Кевин; Хайзер, Гернот (сентябрь 2005 г.). «Драйверы устройств пользовательского уровня: достигнутая производительность». Журнал компьютерных наук и технологий . 20 (5): 654–664. DOI : 10.1007 / s11390-005-0654-4 . S2CID 1121537 . 
  29. ^ Таненбаум, Эндрю С. «Дебаты Таненбаума-Торвальдса, часть II» .
  30. Перейти ↑ Tanenbaum, A., Herder, J. and Bos, H. (май 2006 г.).
  31. ^ Биггс, Саймон; Ли, Дэймон; Хайзер, Гернот (2018). «Жюри такое: дизайн монолитной ОС несовершенен: дизайн на основе микроядра повышает безопасность» . Материалы 9-го Азиатско-Тихоокеанского семинара по системам . Остров Чеджу, Республика Корея: Ассоциация вычислительной техники. С. 1–7. DOI : 10.1145 / 3265723.3265733 .
  32. ^ Шапиро, Джонатан С .; Вебер, Самуэль. Проверка механизма удержания EROS . Конференция IEEE по безопасности и конфиденциальности. Архивировано из оригинала 3 марта 2016 года.
  33. ^ Элькадуве, Дхаммика; Кляйн, Гервин; Эльфинстон, Кевин (2007). Проверенная модель защиты микроядра seL4 . отправлено для публикации.
  34. ^ а б Кляйн, Гервин; Эльфинстон, Кевин; Хайзер, Гернот; Андроник, июнь; Петух, Дэвид; Деррин, Филип; Элькадуве, Дхаммика; Энгельгардт, Кай; Колански, Рафаль; Норриш, Майкл; Сьюэлл, Томас; Туч, Харви; Уинвуд, Саймон (октябрь 2009 г.). seL4: Формальная проверка ядра ОС (PDF) . 22-й симпозиум ACM по принципам операционных систем. Биг Скай, штат Монтана, США.
  35. ^ Элькадуве, Дхаммика; Деррин, Филип; Эльфинстон, Кевин (апрель 2008 г.). Дизайн ядра для изоляции и обеспечения физической памяти . 1-й семинар по изоляции и интеграции во встроенных системах. Глазго, Великобритания. DOI : 10.1145 / 1435458 . Архивировано из оригинального 24 апреля 2010 года . Проверено 17 августа 2009 года .
  36. ^ a b "TUD Home: Операционные системы: Исследования: Микроядро и гипервизор" . Факультет компьютерных наук . Технический университет Дрездена. 12 августа 2010 . Проверено 5 ноября 2011 года .
  37. ^ Стейнберг, Удо; Кауэр, Бернхард (апрель 2010 г.). NOVA: Архитектура безопасной виртуализации на основе микрогипервизора . Eurosys 2010. Париж, Франция. С. 209–222. DOI : 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. DOI : 10.1145 / 2560537 . S2CID 4474342 . 
  40. ↑ Дэвид Л. Миллс и Пол-Хеннинг Камп (28 ноября 2000 г.). «Наноядро» (PDF) . Проверено 28 августа 2017 года .

Дальнейшее чтение [ править ]

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