Войти
Структура монолитных и микроядерных операционных систем соответственно В информатике, a микроядро (часто сокращенно μ-ядро ) - это почти минимальное количество программного обеспечения, которое может предоставить механизмы, необходимые для реализации операционной системы ( ОПЕРАЦИОННЫЕ СИСТЕМЫ). Эти механизмы включают в себя низкоуровневое управление адресным пространством, управление потоком и межпроцессное взаимодействие (IPC).
Если оборудование обеспечивает несколько колец или режимов ЦП, микроядро может быть единственным программным обеспечением, выполняющимся на самом привилегированном уровне, который обычно обозначается как режим супервизора или ядра. Традиционные функции операционной системы, такие как драйверы устройств, стеки протоколов и файловые системы, обычно удаляются из самого микроядра и вместо этого запускаются в user пробел.
С точки зрения размера исходного кода микроядра часто меньше монолитных ядер. Микроядро MINIX 3, например, имеет всего около 12000 строк кода.
Корни микроядер уходят в корни датского пионера компьютеров Пера Бринча Хансена и его работы в датской компьютерной компании Regnecentralen, где он руководил разработкой программного обеспечения для компьютер RC 4000. В 1967 году Regnecentralen устанавливал прототип RC 4000 на польском заводе удобрений в Пулавах. В компьютере использовалась небольшая операционная система реального времени, адаптированная для нужд завода. Бринч Хансен и его команда обеспокоились отсутствием универсальности и возможности повторного использования системы RC 4000. Они опасались, что для каждой установки потребуется отдельная операционная система, поэтому они начали исследовать новые и более общие способы создания программного обеспечения для RC 4000. В 1969 году их усилия привели к созданию RC 4000 Multiprogramming System. Его ядро обеспечивало межпроцессное взаимодействие на основе передачи сообщений до 23 непривилегированных процессов, из которых 8 одновременно были защищены друг от друга. Кроме того, он реализовал планирование временных интервалов программ, выполняемых параллельно, инициирование и управление выполнением программы по запросу других выполняющихся программ, а также инициирование передачи данных на периферийные устройства или от них. Помимо этих элементарных механизмов, у него не было встроенной стратегии для выполнения программы и распределения ресурсов. Эта стратегия должна была быть реализована посредством иерархии запущенных программ, в которой родительские процессы имели полный контроль над дочерними процессами и действовали как их операционные системы.
После работы Бринча Хансена микроядра разрабатывались с 1970-х годов. Термин микроядро само по себе впервые появилось не позднее 1981 года. Микроядра были задуманы как ответ на изменения в компьютерном мире и несколько задач по адаптации существующих «моноядер » к этим новым системам. Все время разрабатывались новые драйверы устройств, стеки протоколов, файловые системы и другие низкоуровневые системы. Этот код обычно размещался в монолитном ядре, поэтому для его работы требовалась значительная работа и тщательное управление кодом. Микроядра были разработаны с идеей, что все эти службы будут реализованы в виде программ в пространстве пользователя, как и любые другие, что позволит монолитно работать с ними, запускать и останавливать их, как любую другую программу. Это не только упростило бы работу с этими службами, но и разделило бы код ядра, чтобы можно было точно настроить его, не беспокоясь о непредвиденных побочных эффектах. Более того, это позволит «строить» совершенно новые операционные системы на общем ядре, что поможет исследованию ОС.
Микроядра были очень горячей темой в 1980-х, когда были представлены первые используемые локальные сети. Ядро AmigaOS Exec было ранним примером, представленным в 1986 г. и использовался в ПК с относительным коммерческим успехом. Отсутствие защиты памяти, которое в других отношениях считается недостатком, позволило этому ядру иметь очень высокую производительность передачи сообщений, поскольку ему не нужно было копировать данные при обмене сообщениями между программами пользовательского пространства.
Те же механизмы Это позволило распределить ядро в пространстве пользователя, а также позволило распределить систему по сетевым каналам. Первые микроядра, особенно Mach, показали неутешительную производительность, но присущие им преимущества оказались настолько значительными, что это стало основным направлением исследований в конце 1990-х годов. Однако за это время скорость компьютеров значительно выросла по сравнению с сетевыми системами, и недостатки в производительности стали преобладать над преимуществами с точки зрения разработки. Было предпринято множество попыток адаптировать существующие системы для повышения производительности, но накладные расходы всегда были значительными, и большая часть этих усилий требовала возврата программ пользовательского пространства в ядро. К 2000 году большинство крупномасштабных (похожих на Mach) усилий прекратились, хотя Apple macOS, выпущенная в 2001 году, использует гибридное ядро под названием XNU, которое объединяет сильно модифицированное (гибридное) ядро OSFMK 7.3 с кодом из BSD UNIX, и это ядро также используется в iOS, tvOS и watchOS. По состоянию на 2012 год GNU Hurd на базе Mach также функционирует и включен в тестовые версии Arch Linux и Debian.
. Хотя основная работа над микроядрами в основном завершена, экспериментаторы продолжали развитие. С тех пор было показано, что многие проблемы производительности более ранних проектов не были фундаментальным ограничением концепции, а были вызваны желанием разработчика использовать одноцелевые системы для реализации как можно большего числа этих услуг. Использование более прагматичного подхода к проблеме, включая ассемблерный код и использование процессора для реализации концепций, обычно поддерживаемых в программном обеспечении, привело к созданию новой серии микроядер со значительно улучшенной производительностью.
Микроядра тесно связаны с экзоядрами. У них также много общего с гипервизорами, но последние не претендуют на минимальность и специализируются на поддержке виртуальных машин ; действительно, микроядро L4 часто находит применение в качестве гипервизора.
Ядра ранних операционных систем были довольно маленькими, отчасти из-за ограниченности памяти компьютера. По мере того, как возможности компьютеров росли, росло и количество устройств, которыми ядро должно было управлять. На протяжении ранней истории Unix ядра, как правило, были небольшими, даже несмотря на то, что они содержали различные реализации драйверов устройств и файловой системы. Когда адресные пространства увеличились с 16 до 32 бит, архитектура ядра больше не ограничивалась архитектурой, и ядра начали расти в размерах.
Berkeley Software Distribution (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 и MINIX 3.
. В серии экспериментов Чен и Бершад сравнили память циклов на инструкцию (MCPI) монолитного Ultrix с микроядром Mach в сочетании с сервером 4.3BSD Unix, работающим в пользовательском пространстве. Их результаты объяснили более низкую производительность Mach более высоким MCPI и продемонстрировали, что IPC сам по себе не несет ответственности за большую часть системных накладных расходов, предполагая, что оптимизации, сфокусированные исключительно на IPC, будут иметь ограниченное влияние. Позднее Лидтке уточнил результаты Чена и Бершада, сделав наблюдение, что основная разница между Ultrix и Mach MCPI была вызвана пропускной способностью пропусков кэша, и пришел к выводу, что резкое сокращение рабочего набора кеша микроядра решит проблему. проблема.
В системе клиент-сервер большая часть обмена данными по существу синхронна, даже при использовании асинхронных примитивов, поскольку типичная операция - это клиент, вызывающий сервер, а затем ожидающий ответа. Поскольку он также поддается более эффективной реализации, большинство микроядер обычно следовали примеру L4 и предоставляли только синхронный примитив IPC. Асинхронный IPC может быть реализован поверх с помощью вспомогательных потоков. Однако опыт показал, что полезность синхронного IPC сомнительна: синхронный IPC навязывает многопоточную архитектуру простым системам, что влечет за собой сложности синхронизации. Более того, вызов сервера, подобный RPC, упорядочивает клиент и сервер, чего следует избегать, если они работают на разных ядрах. Поэтому версии L4, развернутые в коммерческих продуктах, сочли необходимым добавить механизм асинхронного уведомления для лучшей поддержки асинхронной связи. Этот signal -подобный механизм не переносит данные и, следовательно, не требует буферизации ядром. Тем не менее, имея две формы IPC, они нарушили принцип минимальности. Другие версии L4 полностью переключились на асинхронный IPC.
Поскольку синхронный IPC блокирует первую сторону, пока другая не будет готова, неограниченное использование может легко привести к взаимоблокировкам. Более того, клиент может легко организовать атаку отказ в обслуживании на сервере, отправив запрос и никогда не пытаясь получить ответ. Следовательно, синхронный IPC должен предоставлять средства для предотвращения неопределенной блокировки. Многие микроядра предоставляют таймауты для вызовов IPC, что ограничивает время блокировки. На практике выбрать разумные значения тайм-аута сложно, и системы почти неизбежно используют бесконечные тайм-ауты для клиентов и нулевые тайм-ауты для серверов. Как следствие, тенденция заключается в том, чтобы не предоставлять произвольные тайм-ауты, а только флаг, который указывает, что IPC должен немедленно выйти из строя, если партнер не готов. Этот подход эффективно предоставляет выбор из двух значений тайм-аута: нуля и бесконечности. Последние версии L4 и MINIX пошли по этому пути (более старые версии L4 использовали таймауты). QNX избегает проблемы, требуя от клиента указывать буфер ответа как часть вызова отправки сообщения. Когда сервер отвечает, ядро копирует данные в буфер клиента, не дожидаясь явного получения ответа клиентом.
Серверы микроядра по сути являются демонами программы подобны любым другим, за исключением того, что ядро предоставляет некоторым из них привилегии для взаимодействия с частями физической памяти, которые в противном случае недоступны для большинства программ. Это позволяет некоторым серверам, особенно драйверам устройств, напрямую взаимодействовать с оборудованием.
Базовый набор серверов для микроядра общего назначения включает серверы файловой системы, серверы драйверов устройств, сетевые серверы, серверы отображения и серверы устройств пользовательского интерфейса. Этот набор серверов (взят из QNX ) предоставляет примерно набор услуг, предлагаемых Unix монолитным ядром. Необходимые серверы запускаются при запуске системы и предоставляют такие услуги, как доступ к файлам, сети и устройствам для обычных прикладных программ. С такими серверами, работающими в среде пользовательского приложения, разработка сервера похожа на разработку обычного приложения, а не на процесс сборки и загрузки, необходимый для разработки ядра.
Кроме того, многие «сбои» можно исправить простым остановкой и перезапуском сервера. Однако часть состояния системы теряется из-за неисправного сервера, поэтому этот подход требует, чтобы приложения справлялись с ошибкой. Хорошим примером является сервер, отвечающий за TCP / IP соединения: если этот сервер перезапущен, приложения будут испытывать «потерянное» соединение, нормальное явление в сетевой системе. Для других служб сбой менее вероятен и может потребовать изменения кода приложения. Для QNX возможность перезапуска предлагается в виде QNX High Availability Toolkit.
Драйверы устройств часто выполняют прямой доступ к памяти (DMA), и поэтому могут выполнять запись в произвольные места физической памяти, включая различные структуры данных ядра. Поэтому таким водителям нужно доверять. Распространенное заблуждение, что это означает, что они должны быть частью ядра. Фактически, драйвер не заслуживает более или менее доверия, будучи частью ядра.
Хотя запуск драйвера устройства в пользовательском пространстве не обязательно снижает ущерб, который может нанести некорректный драйвер, на практике это полезно для стабильности системы при наличии ошибочных (а не вредоносных) драйверов: нарушения доступа к памяти сам код драйвера (в отличие от устройства) может быть перехвачен оборудованием управления памятью. Кроме того, многие устройства не поддерживают DMA, их драйверы можно сделать ненадежными, запустив их в пространстве пользователя. В последнее время все большее количество компьютеров имеет IOMMU, многие из которых могут использоваться для ограничения доступа устройства к физической памяти. Это также позволяет не доверять драйверам пользовательского режима.
Драйверы пользовательского режима фактически появились раньше микроядер. Michigan Terminal System (MTS) в 1967 году поддерживала драйверы пользовательского пространства (включая поддержку файловой системы), первая операционная система, разработанная с такой возможностью. Исторически с драйверами было меньше проблем, так как количество устройств было небольшим и в любом случае они доверяли, поэтому их наличие в ядре упростило конструкцию и позволило избежать потенциальных проблем с производительностью. Это привело к традиционному стилю «драйвер в ядре» для Unix, Linux и Windows NT. С распространением различных видов периферийных устройств объем кода драйвера увеличился, и в современных операционных системах размер кода ядра превышает размер ядра.
Поскольку микроядро должно позволять создавать произвольные службы операционной системы поверх, оно должно обеспечивать некоторые основные функции. Как минимум, это включает:
Этот минималистичный дизайн был впервые разработан Бринчем Хансеном Nucleus и гипервизор IBM VM. С тех пор это было формализовано в принципе минимальности Лидтке:
Концепция допускается внутри микроядра только в том случае, если ее перенос за пределы ядра, то есть разрешение конкурирующих реализаций, помешает реализации требуемых функций системы.
Все остальное может выполняться в программе пользовательского режима, хотя драйверы устройств, реализованные в виде пользовательских программ, на некоторых архитектурах процессоров могут требовать специальных привилегий для доступа к оборудованию ввода-вывода.
Связанное с принципом минимальности и не менее важное для проектирования микроядра, разделение механизма и политики, это то, что позволяет создавать произвольные системы поверх минимального ядра. Любая политика, встроенная в ядро, не может быть перезаписана на уровне пользователя и, следовательно, ограничивает универсальность микроядра. Политика, реализованная на серверах пользовательского уровня, может быть изменена путем замены серверов (или предоставления приложению возможности выбирать между конкурирующими серверами, предлагающими аналогичные услуги).
Для повышения эффективности большинство микроядер содержат планировщики и управляют таймерами, в нарушение принципа минимальности и принципа разделения политик и механизмов.
Запуск (загрузка ) системы на основе микроядра требует драйверов устройств, которые не являются частью ядра. Обычно это означает, что они упакованы с ядром в загрузочный образ, и ядро поддерживает протокол начальной загрузки, который определяет, как драйверы размещаются и запускаются; это традиционная процедура начальной загрузки микроядер 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) на самом высоком уровне гарантии (Evaluation Assurance Level (EAL) 7) имеет явное требование, чтобы цель оценки была «простой», что является подтверждением практическая невозможность установить истинную надежность сложной системы. К сожалению, опять же, термин «простой» вводит в заблуждение и имеет неточное определение. По крайней мере, Критерии оценки доверенных компьютерных систем Министерства обороны представили несколько более точную формулировку для классов B3 / A1:
«УТС должен [реализовывать] полные, концептуально простые механизмы защиты с точно определенной семантикой. Необходимо направить существенное системное проектирование в направлении минимизации сложности TCB, а также исключения из TCB тех модулей, которые не являются критически важными для защиты ».
— Критерии оценки доверенных компьютерных систем Министерства обороныВ 2018 году документ, представленный в Азиатско-Тихоокеанском регионе Системная конференция заявила, что микроядра были явно более безопасными, чем монолитные ядра, исследовав все опубликованные критические CVE для ядра Linux в то время. Исследование пришло к выводу, что 40% проблем вообще не могут возникнуть в официально проверенном микроядре, и только 4% проблем останутся полностью устраненными в такой системе.
Более поздняя работа над микроядрами была сосредоточена на формальных спецификациях API ядра и формальных доказательствах свойств безопасности API и правильности реализации. Первым примером этого является математическое доказательство механизмов ограничения в EROS, основанное на упрощенной модели EROS API. Совсем недавно (в 2007 г.) был проведен полный набор проверенных машиной доказательств свойств модели защиты seL4, версии L4.
Это привело к тому, что упоминается как микроядра третьего поколения, характеризующиеся ориентированным на безопасность API с доступом к ресурсам, контролируемым возможностями, виртуализацией как первоклассной задачей, новыми подходами к управлению ресурсами ядра и цель проектирования пригодности для формального анализа, помимо обычной цели высокой производительности. Примеры: seL4, Nova, Redox и Fiasco.OC.
В случае seL4 была достигнута полная формальная проверка реализации, т.е. доказательство того, что реализация ядра соответствует его формальной спецификации. Это обеспечивает гарантию того, что свойства, доказанные для API, действительно сохраняются для реального ядра, степень уверенности превышает даже CC EAL7. За ним последовали доказательства свойств обеспечения безопасности API и доказательство, демонстрирующее, что исполняемый двоичный код является правильным переводом реализации C, выводя компилятор из TCB. Взятые вместе, эти доказательства обеспечивают сквозное доказательство свойств безопасности ядра.
Термин наноядро или пикоядро исторически обозначал:
. Также есть как минимум один случай, когда термин наноядро используется для обозначения не маленького ядра, а того, которое поддерживает тактовое разрешение наносекунды.
