Микроядра: Принципы и История Разработки

Введение

Ядро, предоставляющее меньше сервисов, чем традиционное ядро.

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

История

Микроядра уходят корнями к датскому пионеру в области компьютерных технологий Перу Бринчу Хансену и его работе в датской компьютерной компании Regnecentralen, где он руководил разработкой программного обеспечения для компьютера RC 4000. В 1967 году Regnecentralen устанавливал прототип RC 4000 на заводе по производству удобрений Zakłady Azotowe Puławy в Польше. Компьютер использовал небольшую операционную систему реального времени, разработанную для нужд завода. Бринч Хансен и его команда обеспокоились отсутствием универсальности и возможности повторного использования системы RC 4000. Они опасались, что для каждой установки потребуется отдельная операционная система, поэтому начали изучать новые и более общие способы создания программного обеспечения для RC 4000. В 1969 году их усилия увенчались завершением многопрограммной системы RC 4000. Её ядро обеспечивало межпроцессное взаимодействие на основе передачи сообщений для до 23 непривилегированных процессов, из которых 8 могли одновременно быть защищены друг от друга. Оно также реализовало планирование временных интервалов выполнения программ, выполняемых параллельно, запуск и управление выполнением программ по запросу других работающих программ, а также запуск передачи данных к или от периферийных устройств. Помимо этих элементарных механизмов, в нём не было встроенной стратегии выполнения программ и распределения ресурсов. Эта стратегия должна была быть реализована иерархией запущенных программ, в которой родительские процессы имели полный контроль над дочерними процессами и действовали как их операционные системы. После работы Бринча Хансена микроядра разрабатывались с 1970-х годов. Сам термин «микроядро» впервые появился не позднее 1981 года. Микроядра были задуманы как ответ на изменения в мире компьютеров и на ряд проблем, связанных с адаптацией существующих «монолитных ядер» к этим новым системам. Постоянно разрабатывались новые драйверы устройств, стеки протоколов, файловые системы и другие низкоуровневые системы. Этот код обычно располагался в монолитном ядре, и поэтому требовал значительной работы и тщательного управления кодом. Микроядра были разработаны с идеей, что все эти сервисы будут реализованы как программы пользовательского пространства, как и любые другие, что позволит работать над ними комплексно и запускать и останавливать их как любую другую программу. Это не только позволило бы упростить работу с этими сервисами, но и отделило код ядра, чтобы его можно было точно настроить, не опасаясь непредвиденных побочных эффектов. Кроме того, это позволило бы «создавать» совершенно новые операционные системы на основе общего ядра, что способствовало бы исследованиям в области ОС. Микроядра были очень актуальной темой в 1980-х годах, когда были представлены первые работоспособные локальные сети. Ядро AmigaOS Exec было ранним примером, представленным в 1986 году и использовавшимся в ПК с относительным коммерческим успехом. Отсутствие защиты памяти, которое в других аспектах считалось недостатком, позволило этому ядру достичь очень высокой производительности передачи сообщений, поскольку не требовалось копировать данные при обмене сообщениями между программами пользовательского пространства. Те же механизмы, которые позволили ядру распределяться в пользовательском пространстве, также позволили системе распределяться по сетевым соединениям. Первые микроядра, в частности Mach, созданные Ричардом Рашидом, показали разочаровывающую производительность, но их потенциальные преимущества казались настолько велики, что это было важным направлением исследований до конца 1990-х годов. Однако в это время скорость компьютеров значительно возросла по сравнению со скоростью сетевых систем, и недостатки в производительности стали перевешивать преимущества в плане разработки. Было предпринято много попыток адаптировать существующие системы для повышения производительности, но накладные расходы всегда были значительными, и большинство этих усилий требовали возврата программ пользовательского пространства обратно в ядро. К 2000 году большинство масштабных проектов по созданию ядра Mach были завершены, хотя macOS от Apple, выпущенная в 2001 году, по-прежнему использует гибридное ядро под названием XNU, которое сочетает в себе сильно модифицированное (гибридное) ядро OSF/1 (ядро OSFMK 7.3) с кодом BSD UNIX, и это ядро также используется в iOS, tvOS и watchOS. Windows NT, начиная с NT 3.1 и продолжая с Windows 11, использует гибридную архитектуру ядра. По состоянию на 2012 год GNU Hurd на базе Mach также функционирует и включен в тестовые версии Arch Linux и Debian. Хотя основные работы над микроядрами в значительной степени завершились, экспериментаторы продолжали разработки. Впоследствии было показано, что многие проблемы с производительностью более ранних конструкций не были фундаментальным ограничением концепции, а скорее были связаны с желанием разработчиков использовать системы специального назначения для реализации как можно большего числа этих сервисов. Применение более прагматичного подхода к проблеме, включая ассемблерный код и использование возможностей процессора для обеспечения концепций, обычно поддерживаемых программным обеспечением, привело к созданию новой серии микроядер с значительно улучшенной производительностью. Микроядра тесно связаны с экзоядрами. Они также имеют много общего с гипервизорами, но последние не претендуют на минимальность и специализируются на поддержке виртуальных машин; микроядро L4 часто используется в качестве гипервизора.

Microkernels trace their roots back to Danish computer pioneer Per Brinch Hansen and his tenure in Danish computer company Regnecentralen where he led software development efforts for the RC 4000 computer. In 1967, Regnecentralen was installing a RC 4000 prototype in the Zakłady Azotowe Puławy fertilizer plant in Poland. The computer used a small real time operating system tailored for the needs of the plant. Brinch Hansen and his team became concerned with the lack of generality and reusability of the RC 4000 system. They feared that each installation would require a different operating system so they started to investigate novel and more general ways of creating software for the RC 4000. In 1969, their effort resulted in the completion of the RC 4000 Multiprogramming System. Its nucleus provided inter process communication based on message passing for up to 23 unprivileged processes, out of which 8 at a time were protected from one another. It further implemented scheduling of time slices of programs executed in parallel, initiation and control of program execution at the request of other running programs, and initiation of data transfers to or from peripherals. Besides these elementary mechanisms, it had no built in strategy for program execution and resource allocation. This strategy was to be implemented by a hierarchy of running programs in which parent processes had complete control over child processes and acted as their operating systems. Following Brinch Hansen's work, microkernels have been developed since the 1970s. The term microkernel itself first appeared no later than 1981. Microkernels were meant as a response to changes in the computer world, and to several challenges adapting existing "mono kernels" to these new systems. New device drivers, protocol stacks, file systems and other low level systems were being developed all the time. This code was normally located in the monolithic kernel, and thus required considerable work and careful code management to work on. Microkernels were developed with the idea that all of these services would be implemented as user space programs, like any other, allowing them to be worked on monolithically and started and stopped like any other program. This would not only allow these services to be more easily worked on, but also separated the kernel code to allow it to be finely tuned without worrying about unintended side effects. Moreover, it would allow entirely new operating systems to be "built up" on a common core, aiding OS research. Microkernels were a very hot topic in the 1980s when the first usable local area networks were being introduced The AmigaOS Exec kernel was an early example, introduced in 1986 and used in a PC with relative commercial success. The lack of memory protection, considered in other respects a flaw, allowed this kernel to have very high message passing performance because it did not need to copy data while exchanging messages between user space programs. The same mechanisms that allowed the kernel to be distributed into user space also allowed the system to be distributed across network links. The first microkernels, notably Mach created by Richard Rashid, proved to have disappointing performance, but the inherent advantages appeared so great that it was a major line of research into the late 1990s. However, during this time the speed of computers grew greatly in relation to networking systems, and the disadvantages in performance came to overwhelm the advantages in development terms. Many attempts were made to adapt the existing systems to have better performance, but the overhead was always considerable and most of these efforts required the user space programs to be moved back into the kernel. By 2000, most large scale Mach kernel efforts had ended, although Apple's macOS, released in 2001, still uses a hybrid kernel called XNU, which combines a heavily modified (hybrid) OSF/1's Mach kernel (OSFMK 7.3 kernel) with code from BSD UNIX, and this kernel is also used in iOS, tvOS, and watchOS. Windows NT, starting with NT 3.1 and continuing with Windows 11, uses a hybrid kernel design. as of 2012, the Mach based GNU Hurd is also functional and included in testing versions of Arch Linux and Debian. Although major work on microkernels had largely ended, experimenters continued development. It has since been shown that many of the performance problems of earlier designs were not a fundamental limitation of the concept, but instead due to the designer's desire to use single purpose systems to implement as many of these services as possible. Using a more pragmatic approach to the problem, including assembly code and relying on the processor to enforce concepts normally supported in software led to a new series of microkernels with dramatically improved performance. Microkernels are closely related to exokernels. They also have much in common with hypervisors, but the latter make no claim to minimality and are specialized to supporting virtual machines; the L4 microkernel frequently finds use in a hypervisor capacity.

Введение

Ранние ядра операционных систем были относительно небольшими, отчасти из-за ограниченного объема компьютерной памяти. По мере увеличения вычислительной мощности компьютеров росло и количество устройств, которыми требовалось управлять ядру. На протяжении большей части ранней истории Unix, ядра оставались небольшими, несмотря на то, что включали в себя различные драйверы устройств и реализации файловых систем. Когда адресные пространства увеличились с 16 до 32 бит, проектирование ядра перестало быть ограниченным аппаратной архитектурой, и ядра начали увеличиваться в размерах. Распространение Berkeley Software Distribution (BSD) Unix положило начало эпохе больших ядер. Помимо управления базовой системой, состоящей из процессора, дисков и принтеров, BSD добавила полноценную сетевую систему TCP/IP и ряд "виртуальных" устройств, позволявших существующим программам работать через сеть "незаметно". Этот рост продолжался на протяжении многих лет, что привело к созданию ядер, содержащих миллионы строк исходного кода. В результате этого роста ядра стали подвержены ошибкам и их обслуживание становилось все более сложным. Микроядро было разработано для решения проблемы роста ядер и связанных с этим трудностей. Теоретически, архитектура микроядра обеспечивает более простое управление кодом благодаря его разделению на сервисы, работающие в пользовательском пространстве. Это также повышает безопасность и стабильность за счет уменьшения объема кода, выполняющегося в режиме ядра. Например, если сетевой сервис аварийно завершил работу из-за переполнения буфера, будет повреждена только память этого сервиса, а остальная часть системы продолжит функционировать.

Межпроцессная связь

Межпроцессное взаимодействие (МПК) — это любой механизм, позволяющий отдельным процессам обмениваться данными, как правило, посредством отправки сообщений. Общая память, в строгом определении, также является механизмом межпроцессного взаимодействия, но аббревиатура 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, будут иметь ограниченный эффект. Лидтке позже уточнил результаты Чена и Бершада, отметив, что основная часть разницы между MCPI Ultrix и Mach была вызвана промахами кэша и придя к выводу, что резкое сокращение рабочего набора кэша микроядра решит проблему. В клиент-серверной системе большая часть коммуникации по сути синхронна, даже если используются асинхронные примитивы, поскольку типичная операция — это клиент, вызывающий сервер, а затем ожидающий ответа. Поскольку это также способствует более эффективной реализации, большинство микроядер обычно последовали примеру L4 и предоставили только синхронный IPC-примитив. Асинхронное IPC можно реализовать поверх с использованием вспомогательных потоков. Однако опыт показал, что полезность синхронного IPC сомнительна: синхронное IPC навязывает многопоточную структуру в противном случае простым системам, что приводит к сложностям синхронизации. Кроме того, вызов сервера в стиле RPC последовательно распределяет клиент и сервер, чего следует избегать, если они работают на разных ядрах. Поэтому версии L4, развернутые в коммерческих продуктах, сочли необходимым добавить механизм асинхронного уведомления для лучшей поддержки асинхронной коммуникации. Этот механизм, подобный сигналу, не передает данные и, следовательно, не требует буферизации ядром. Имея две формы IPC, они, тем не менее, нарушили принцип минимальности. Другие версии L4 перешли на полностью асинхронное IPC. Поскольку синхронное IPC блокирует первую сторону до готовности другой, неограниченное использование может легко привести к взаимоблокировкам. Кроме того, клиент может легко организовать атаку типа «отказ в обслуживании» на сервер, отправив запрос и не пытаясь получить ответ. Поэтому синхронное IPC должно предоставлять средства для предотвращения неопределенной блокировки. Многие микроядра предоставляют тайм-ауты для вызовов IPC, которые ограничивают время блокировки. На практике выбор разумных значений тайм-аута затруднителен, и системы почти неизбежно используют бесконечные тайм-ауты для клиентов и нулевые тайм-ауты для серверов. В результате тенденция заключается в том, чтобы не предоставлять произвольные тайм-ауты, а только флаг, указывающий, что IPC должно завершиться неудачей, если партнер не готов. Этот подход фактически предоставляет выбор двух значений тайм-аута: нуля и бесконечности. Недавние версии L4 и MINIX пошли по этому пути (более старые версии L4 использовали тайм-ауты). QNX избегает этой проблемы, требуя от клиента указать буфер ответа как часть вызова отправки сообщения. Когда сервер отвечает, ядро копирует данные в буфер клиента, не дожидаясь, пока клиент явно получит ответ.

Inter process communication (IPC) is any mechanism which allows separate processes to communicate with each other, usually by sending messages. Shared memory is, strictly defined, also an inter process communication mechanism, but the abbreviation IPC usually refers to message passing only, and it is the latter that is particularly relevant to microkernels. IPC allows the operating system to be built from a number of smaller programs called servers, which are used by other programs on the system, invoked via IPC. Most or all support for peripheral hardware is handled in this fashion, with servers for device drivers, network protocol stacks, file systems, graphics, etc. IPC can be synchronous or asynchronous. Asynchronous IPC is analogous to network communication: the sender dispatches a message and continues executing. The receiver checks (polls) for the availability of the message, or is alerted to it via some notification mechanism. Asynchronous IPC requires that the kernel maintains buffers and queues for messages, and deals with buffer overflows; it also requires double copying of messages (sender to kernel and kernel to receiver). In synchronous IPC, the first party (sender or receiver) blocks until the other party is ready to perform the IPC. It does not require buffering or multiple copies, but the implicit rendezvous can make programming tricky. Most programmers prefer asynchronous send and synchronous receive. First generation microkernels typically supported synchronous as well as asynchronous IPC, and suffered from poor IPC performance. Jochen Liedtke assumed the design and implementation of the IPC mechanisms to be the underlying reason for this poor performance. In his L4 microkernel he pioneered methods that lowered IPC costs by an order of magnitude. These include an IPC system call that supports a send as well as a receive operation, making all IPC synchronous, and passing as much data as possible in registers. Furthermore, Liedtke introduced the concept of the direct process switch, where during an IPC execution an (incomplete) context switch is performed from the sender directly to the receiver. If, as in L4, part or all of the message is passed in registers, this transfers the in register part of the message without any copying at all. Furthermore, the overhead of invoking the scheduler is avoided; this is especially beneficial in the common case where IPC is used in a remote procedure call (RPC) type fashion by a client invoking a server. Another optimization, called lazy scheduling, avoids traversing scheduling queues during IPC by leaving threads that block during IPC in the ready queue. Once the scheduler is invoked, it moves such threads to the appropriate waiting queue. As in many cases a thread gets unblocked before the next scheduler invocation, this approach saves significant work. Similar approaches have since been adopted by QNX and MINIX 3. In a series of experiments, Chen and Bershad compared memory cycles per instruction (MCPI) of monolithic Ultrix with those of microkernel Mach combined with a 4.3BSD Unix server running in user space. Their results explained Mach's poorer performance by higher MCPI and demonstrated that IPC alone is not responsible for much of the system overhead, suggesting that optimizations focused exclusively on IPC will have a limited effect. Liedtke later refined Chen and Bershad's results by making an observation that the bulk of the difference between Ultrix and Mach MCPI was caused by capacity cache misses and concluding that drastically reducing the cache working set of a microkernel will solve the problem. In a client server system, most communication is essentially synchronous, even if using asynchronous primitives, as the typical operation is a client invoking a server and then waiting for a reply. As it also lends itself to more efficient implementation, most microkernels generally followed L4's lead and only provided a synchronous IPC primitive. Asynchronous IPC could be implemented on top by using helper threads. However, experience has shown that the utility of synchronous IPC is dubious: synchronous IPC forces a multi threaded design onto otherwise simple systems, with the resulting synchronization complexities. Moreover, an RPC like server invocation sequentializes client and server, which should be avoided if they are running on separate cores. Versions of L4 deployed in commercial products have therefore found it necessary to add an asynchronous notification mechanism to better support asynchronous communication. This signal like mechanism does not carry data and therefore does not require buffering by the kernel. By having two forms of IPC, they have nonetheless violated the principle of minimality. Other versions of L4 have switched to asynchronous IPC completely. As synchronous IPC blocks the first party until the other is ready, unrestricted use could easily lead to deadlocks. Furthermore, a client could easily mount a denial of service attack on a server by sending a request and never attempting to receive the reply. Therefore, synchronous IPC must provide a means to prevent indefinite blocking. Many microkernels provide timeouts on IPC calls, which limit the blocking time. In practice, choosing sensible timeout values is difficult, and systems almost inevitably use infinite timeouts for clients and zero timeouts for servers. As a consequence, the trend is towards not providing arbitrary timeouts, but only a flag which indicates that the IPC should fail immediately if the partner is not ready. This approach effectively provides a choice of the two timeout values of zero and infinity. Recent versions of L4 and MINIX have gone down this path (older versions of L4 used timeouts). QNX avoids the problem by requiring the client to specify the reply buffer as part of the message send call. When the server replies the kernel copies the data to the client's buffer, without having to wait for the client to receive the response explicitly.

Серверы

Серверы микроядра по сути являются демонами, как и любые другие программы, за исключением того, что ядро предоставляет некоторым из них привилегии для доступа к областям физической памяти, которые обычно недоступны большинству программ. Это позволяет некоторым серверам, в частности драйверам устройств, взаимодействовать напрямую с аппаратным обеспечением. Базовый набор серверов для микроядра общего назначения включает серверы файловых систем, серверы драйверов устройств, сетевые серверы, серверы дисплея и серверы устройств пользовательского интерфейса. Этот набор серверов (взятый из QNX) предоставляет примерно тот же набор сервисов, что и монолитное ядро Unix. Необходимые серверы запускаются при загрузке системы и предоставляют сервисы, такие как доступ к файлам, сети и устройствам, обычным приложениям. Поскольку такие серверы работают в среде пользовательского приложения, разработка сервера больше похожа на обычную разработку приложений, чем на процесс сборки и загрузки, необходимый для разработки ядра. Кроме того, многие "сбои" можно устранить, просто остановив и перезапустив сервер. Однако при сбое сервера теряется часть состояния системы, поэтому этот подход требует, чтобы приложения умели обрабатывать отказы. Хорошим примером является сервер, отвечающий за TCP/IP соединения: при его перезапуске приложения будут испытывать "разрыв" соединения, что является нормальным явлением в сетевой системе. Для других сервисов отказ менее вероятен и может потребовать изменений в коде приложения. В QNX возможность перезапуска предоставляется в составе QNX High Availability Toolkit.

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

Драйверы устройств часто выполняют прямой доступ к памяти (DMA) и, следовательно, могут записывать в произвольные области физической памяти, включая различные структуры данных ядра. Поэтому этим драйверам необходимо доверять. Распространено ошибочное мнение, что это означает необходимость их включения в ядро. На самом деле, доверие к драйверу не повышается и не понижается от того, является ли он частью ядра. Хотя запуск драйвера устройства в пользовательском пространстве не обязательно уменьшает ущерб, который может нанести некорректно работающий драйвер, на практике это полезно для стабильности системы при наличии драйверов с ошибками (а не злонамеренных): нарушения доступа к памяти самим кодом драйвера (а не устройством) все еще могут быть перехвачены аппаратным обеспечением управления памятью. Кроме того, многие устройства не поддерживают DMA, и их драйверы могут быть сделаны ненадежными при работе в пользовательском пространстве. В последнее время все большее число компьютеров оснащаются IOMMU, многие из которых можно использовать для ограничения доступа устройства к физической памяти. Это также позволяет считать драйверы пользовательского режима ненадежными. Драйверы пользовательского режима на самом деле появились раньше микроядер. Michigan Terminal System (MTS) в 1967 году поддерживала драйверы пользовательского пространства (включая поддержку файловой системы), став первой операционной системой, разработанной с такой возможностью. Исторически драйверы представляли меньшую проблему, поскольку количество устройств было небольшим и им доверяли, поэтому размещение их в ядре упрощало разработку и избегало потенциальных проблем с производительностью. Это привело к традиционной модели драйверов в ядре, используемой в Unix, Linux и Windows NT. С ростом количества различных периферийных устройств объем кода драйверов значительно увеличился и в современных операционных системах по размеру превосходит сам код ядра.

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

Преимущества микроядер в области безопасности часто обсуждаются. В контексте безопасности принцип минимальности микроядра, по мнению некоторых, является прямым следствием принципа наименьших привилегий, согласно которому весь код должен обладать только теми привилегиями, которые необходимы для обеспечения требуемой функциональности. Минимальность требует, чтобы доверенная вычислительная база системы (TCB) была сведена к минимуму. Поскольку ядро (код, выполняющийся в привилегированном режиме аппаратного обеспечения) имеет неконтролируемый доступ к любым данным и, следовательно, может нарушить их целостность или конфиденциальность, ядро всегда является частью TCB. Его минимизация естественна при разработке, ориентированной на безопасность. Следовательно, архитектуры микроядер использовались в системах, предназначенных для приложений с высокими требованиями к безопасности, включая KeyKOS, EROS и военные системы. Фактически, в общих критериях (CC) на самом высоком уровне заверения (Уровень гарантии оценки (EAL) 7) содержится явное требование, чтобы объект оценки был "простым", что признает практическую невозможность установления подлинной надежности для сложной системы. Вновь, термин "простой" является вводящим в заблуждение и недостаточно четко определенным. По крайней мере, в критериях оценки надежных компьютерных систем Министерства обороны были введены более точные формулировки для классов B3/A1: text="ТКБ должен [реализовать] полные, концептуально простые механизмы защиты с четко определенной семантикой. Значительные системно-инженерные усилия должны быть направлены на минимизацию сложности ТКБ, а также на исключение из ТКБ тех модулей, которые не критичны для защиты."|sign=|source=Критерии оценки надежных компьютерных систем Министерства обороны.

The security benefits of microkernels have been frequently discussed. In the context of security the minimality principle of microkernels is, some have argued, a direct consequence of the principle of least privilege, according to which all code should have only the privileges needed to provide required functionality. Minimality requires that a system's trusted computing base (TCB) should be kept minimal. As the kernel (the code that executes in the privileged mode of the hardware) has unvetted access to any data and can thus violate its integrity or confidentiality, the kernel is always part of the TCB. Minimizing it is natural in a security driven design. Consequently, microkernel designs have been used for systems designed for high security applications, including KeyKOS, EROS and military systems. In fact common criteria (CC) at the highest assurance level (Evaluation Assurance Level (EAL) 7) has an explicit requirement that the target of evaluation be "simple", an acknowledgment of the practical impossibility of establishing true trustworthiness for a complex system. Again, the term "simple" is misleading and ill defined. At least the Department of Defense Trusted Computer System Evaluation Criteria introduced somewhat more precise verbiage at the B3/A1 classes:

text="The TCB shall [implement] complete, conceptually simple protection mechanisms with precisely defined semantics. Significant system engineering shall be directed toward minimizing the complexity of the TCB, as well as excluding from the TCB those modules that are not protection critical. "|sign=|source=Department of Defense Trusted Computer System Evaluation Criteria

In 2018, a paper presented at the Asia Pacific Systems Conference claimed that microkernels were demonstrably safer than monolithic kernels by investigating all published critical CVEs for the Linux kernel at the time. The study concluded that 40% of the issues could not occur at all in a formally verified microkernel, and only 4% of the issues would remain entirely unmitigated in such a system.

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