Micronúcleo

En informática , un microkernel (a menudo abreviado como μ-kernel ) es la cantidad mínima de software que proporciona los mecanismos necesarios para implementar un sistema operativo (SO). Estos mecanismos incluyen la gestión del espacio de direcciones de bajo nivel , la gestión de subprocesos y la comunicación entre procesos (IPC).

Si el hardware proporciona múltiples anillos o modos de CPU , el microkernel puede ser el único software que se ejecuta en el nivel más privilegiado, que generalmente se denomina modo supervisor o modo kernel . Las funciones tradicionales del sistema operativo, como los controladores de dispositivos , las pilas de protocolos y los sistemas de archivos , normalmente se eliminan del microkernel y se ejecutan en el espacio de usuario . ^{[ 1 ]}

Los microkernels suelen tener menos código fuente que los kernels monolíticos . El microkernel MINIX 3 , por ejemplo, tiene solo aproximadamente 12.000 líneas de código. ^{[ 2 ]}

Los microkernels tienen sus raíces en el pionero informático danés Per Brinch Hansen y su etapa en la empresa informática danesa Regnecentralen , donde dirigió los esfuerzos de desarrollo de software para el ordenador RC 4000. ^{[ 3 ]} En 1967, Regnecentralen estaba instalando un prototipo del RC 4000 en la planta de fertilizantes Zakłady Azotowe Puławy en Polonia. El ordenador utilizaba un pequeño sistema operativo en tiempo real adaptado a las necesidades de la planta. Brinch Hansen y su equipo se preocuparon por la falta de generalidad y reutilización del sistema RC 4000. Temían que cada instalación requiriera un sistema operativo diferente, por lo que investigaron formas novedosas y más generales de crear software para el RC 4000. ^{[ 4 ]} En 1969, su esfuerzo dio como resultado la finalización del Sistema Multiprogramador RC 4000 . Su núcleo proporcionaba comunicación entre procesos basada en el paso de mensajes para hasta 23 procesos sin privilegios, de los cuales 8 estaban protegidos entre sí. Además, implementaba la planificación de segmentos de tiempo de programas ejecutados en paralelo, el inicio y control de la ejecución de programas a petición de otros programas en ejecución, y el inicio de transferencias de datos hacia o desde periféricos. Aparte de estos mecanismos elementales, no tenía una estrategia integrada para la ejecución de programas y la asignación de recursos. Esta estrategia se implementaría mediante una jerarquía de programas en ejecución en la que los procesos padre tenían control total sobre los procesos hijo y actuaban como sus sistemas operativos. ^{[ 5 ] [ 6 ]}

A partir del trabajo de Brinch Hansen, los microkernels se han desarrollado desde la década de 1970. ^{[ 7 ]} El término microkernel apareció por primera vez no más tarde de 1981. ^{[ 8 ]} Los microkernels surgieron como respuesta a los cambios en el mundo de la informática y a los diversos desafíos que suponía adaptar los " monokernels " existentes a estos nuevos sistemas. Constantemente se desarrollaban nuevos controladores de dispositivos, pilas de protocolos, sistemas de archivos y otros sistemas de bajo nivel. Este código normalmente se ubicaba en el kernel monolítico y, por lo tanto, requería un trabajo considerable y una gestión de código cuidadosa. Los microkernels se desarrollaron con la idea de que todos estos servicios se implementarían como programas en el espacio de usuario, como cualquier otro, lo que permitiría trabajar en ellos de forma monolítica e iniciarlos y detenerlos como cualquier otro programa. Esto no solo facilitaría el trabajo con estos servicios, sino que también separaría el código del kernel para permitir su ajuste fino sin preocuparse por efectos secundarios no deseados. Además, permitiría "construir" sistemas operativos completamente nuevos sobre un núcleo común, lo que facilitaría la investigación de los sistemas operativos.

Los microkernels fueron un tema candente en la década de 1980, cuando se introdujeron las primeras redes de área local utilizables. ^{[ 9 ]} El kernel AmigaOS Exec fue un ejemplo temprano, introducido en 1986 y utilizado en una PC con relativo éxito comercial. La falta de protección de memoria, considerada en otros aspectos una falla, permitió que este kernel tuviera un alto rendimiento en el paso de mensajes, ya que no necesitaba copiar datos mientras intercambiaba mensajes entre programas del espacio de usuario. ^{[ 10 ]}

Los mismos mecanismos que permitieron distribuir el núcleo en el espacio de usuario también permitieron distribuir el sistema a través de enlaces de red. Los primeros micronúcleos, en particular Mach , creado por Richard Rashid , demostraron tener un rendimiento decepcionante, pero las ventajas inherentes parecían tan grandes que se convirtieron en una importante línea de investigación hasta finales de la década de 1990. ^{[ 11 ]} Sin embargo, durante este tiempo la velocidad de las computadoras aumentó enormemente en relación con los sistemas de red, y las desventajas en el rendimiento llegaron a superar las ventajas en términos de desarrollo.

Se hicieron muchos intentos para adaptar los sistemas existentes y mejorar su rendimiento, pero la sobrecarga siempre fue considerable y la mayoría de estos esfuerzos requirieron que los programas del espacio de usuario se trasladaran de nuevo al núcleo. Para el año 2000, la mayoría de los esfuerzos a gran escala para el núcleo Mach habían terminado, aunque macOS de Apple , lanzado en 2001, todavía utiliza un núcleo híbrido llamado XNU , que combina un núcleo Mach de OSF/1 modificado (híbrido) (núcleo OSF MK 7.3) con código de BSD UNIX; ^{[ 12 ] [ 13 ]} este núcleo también se utiliza en iOS , tvOS y watchOS . Windows NT , a partir de NT 3.1 y continuando con Windows 11 , utiliza un diseño de núcleo híbrido. A partir de 2012, el GNU Hurd basado en Mach también es funcional y está incluido en las versiones de prueba de Arch Linux y Debian .

Aunque el trabajo principal sobre microkernels había concluido en gran medida, los experimentadores continuaron su desarrollo. ^{[ 14 ] [ 15 ]} El uso de un enfoque más pragmático del problema, que incluía código ensamblador y se basaba en el procesador para aplicar conceptos normalmente soportados en software, condujo a una nueva serie de microkernels con un rendimiento notablemente mejorado.

Los microkernels están estrechamente relacionados con los exokernels . ^{[ 16 ]} También tienen mucho en común con los hipervisores , ^{[ 17 ]} pero estos últimos no pretenden ser minimalistas y están especializados en soportar máquinas virtuales ; el microkernel L4 se utiliza frecuentemente como hipervisor.

Los primeros núcleos de los sistemas operativos eran bastante pequeños, en parte debido a la limitación de la memoria de las computadoras. A medida que la capacidad de las computadoras aumentaba, también lo hacía el número de dispositivos que el núcleo debía controlar. Durante los inicios de Unix , los núcleos solían ser pequeños, a pesar de contener diversos controladores de dispositivos e implementaciones de sistemas de archivos . Cuando los espacios de direcciones aumentaron de 16 a 32 bits, el diseño del núcleo dejó de estar condicionado por la arquitectura del hardware y los núcleos se hicieron más grandes.

La distribución de software Berkeley (BSD) de Unix marcó el inicio de la era de los núcleos más grandes. Además de operar un sistema básico compuesto por la CPU, discos e impresoras, BSD añadió un sistema de red TCP/IP completo y varios dispositivos "virtuales" que permitían que los programas existentes funcionaran de forma "invisible" a través de la red. Este crecimiento continuó durante muchos años, dando como resultado núcleos con millones de líneas de código fuente . Como consecuencia de este crecimiento, los núcleos eran propensos a errores y su mantenimiento se volvió cada vez más difícil.

El microkernel se diseñó para abordar este crecimiento de kernels y las dificultades que de ello se derivaban. En teoría, el diseño del microkernel facilita la gestión del código gracias a su división en servicios de espacio de usuario . Esto también permite una mayor seguridad y estabilidad, derivada de la menor cantidad de código que se ejecuta en modo kernel . Por ejemplo, si un servicio de red falla debido a un desbordamiento de búfer , solo se corrompería la memoria de dicho servicio, dejando el resto del sistema operativo.

La comunicación entre procesos (IPC) es cualquier mecanismo que permite que procesos independientes se comuniquen entre sí, generalmente mediante el envío de mensajes . La memoria compartida , estrictamente hablando, también es un mecanismo de comunicación entre procesos, pero la abreviatura IPC suele referirse únicamente al paso de mensajes, y es este último aspecto el que resulta particularmente relevante para los microkernels. La IPC permite que el sistema operativo se construya a partir de varios programas más pequeños llamados servidores, que son utilizados por otros programas del sistema, invocados mediante IPC. La mayor parte, o incluso la totalidad, del soporte para hardware periférico se gestiona de esta manera, con servidores para controladores de dispositivos, pilas de protocolos de red , sistemas de archivos, gráficos, etc.

La comunicación entre procesos (IPC) puede ser síncrona o asíncrona. La IPC asíncrona es análoga a la comunicación en red: el emisor envía un mensaje y continúa su ejecución. El receptor comprueba ( sondea ) la disponibilidad del mensaje o recibe una notificación. La IPC asíncrona requiere que el núcleo mantenga búferes y colas para los mensajes y gestione los desbordamientos de búfer; también requiere la doble copia de los mensajes (del emisor al núcleo y del núcleo al receptor). En la IPC síncrona, la primera parte (emisor o receptor) se bloquea hasta que la otra esté lista para realizar la comunicación. No requiere almacenamiento en búfer ni múltiples copias, pero el encuentro implícito puede complicar la programación. La mayoría de los programadores prefieren el envío asíncrono y la recepción síncrona.

Los microkernels de primera generación generalmente admitían IPC síncrono y asíncrono, y sufrían de un rendimiento deficiente en IPC. Jochen Liedtke asumió que el diseño e implementación de los mecanismos de IPC eran la causa subyacente de este bajo rendimiento. En su microkernel L4, fue pionero en métodos que redujeron los costos de IPC en un orden de magnitud . ^{[ 18 ]} Estos incluyen una llamada al sistema IPC que admite una operación de envío y recepción, haciendo que todo el IPC sea síncrono y pasando la mayor cantidad de datos posible en registros. Además, Liedtke introdujo el concepto de cambio de proceso directo , donde durante una ejecución de IPC se realiza un cambio de contexto (incompleto) del remitente directamente al receptor. Si, como en L4, parte o la totalidad del mensaje se pasa en registros, esto transfiere la parte del mensaje en los registros sin ninguna copia. Además, se evita la sobrecarga de invocar al planificador; esto es especialmente beneficioso en el caso común en que IPC se utiliza de forma similar a una llamada a procedimiento remoto (RPC) por un cliente que invoca a un servidor. Otra optimización, denominada planificación diferida , evita recorrer las colas de planificación durante la comunicación entre procesos (IPC) al dejar los hilos que se bloquean durante la IPC en la cola de listos. Una vez que se invoca al planificador, este mueve dichos hilos a la cola de espera correspondiente. Dado que en muchos casos un hilo se desbloquea antes de la siguiente invocación del planificador, este enfoque ahorra una cantidad considerable de trabajo. Desde entonces, QNX y MINIX 3 han adoptado enfoques similares .

En una serie de experimentos, Chen y Bershad compararon los ciclos de memoria por instrucción (MCPI) del Ultrix monolítico con los del microkernel Mach combinado con un servidor Unix 4.3BSD ejecutándose en el espacio de usuario . Sus resultados explicaron el peor rendimiento de Mach por un MCPI más alto y demostraron que el IPC por sí solo no es responsable de gran parte de la sobrecarga del sistema, lo que sugiere que las optimizaciones centradas exclusivamente en el IPC tendrán un efecto limitado. ^{[ 19 ]} Posteriormente, Liedtke refinó los resultados de Chen y Bershad al observar que la mayor parte de la diferencia entre el MCPI de Ultrix y Mach se debía a fallos de caché de capacidad y concluyó que reducir drásticamente el conjunto de trabajo de caché de un microkernel resolvería el problema. ^{[ 20 ]}

En un sistema cliente-servidor, la mayor parte de la comunicación es esencialmente síncrona, incluso utilizando primitivas asíncronas, ya que la operación típica consiste en que un cliente invoque a un servidor y espere una respuesta. Dado que esto también facilita una implementación más eficiente, la mayoría de los microkernels generalmente siguieron el ejemplo de L4 y solo proporcionaron una primitiva de comunicación entre procesos (IPC) síncrona. La IPC asíncrona podría implementarse mediante el uso de hilos auxiliares. Sin embargo, la experiencia ha demostrado que la utilidad de la IPC síncrona es dudosa: impone un diseño multihilo a sistemas que de otro modo serían simples, con las consiguientes complejidades de sincronización. Además, una invocación de servidor similar a RPC secuencializa al cliente y al servidor, lo cual debe evitarse si se ejecutan en núcleos separados. Por lo tanto, las versiones de L4 implementadas en productos comerciales han considerado necesario agregar un mecanismo de notificación asíncrona para brindar un mejor soporte a la comunicación asíncrona. Este mecanismo, similar a una señal , no transporta datos y, por lo tanto, no requiere almacenamiento en búfer por parte del kernel. Sin embargo, al tener dos formas de IPC, han violado el principio de minimalidad. Otras versiones de L4 han cambiado completamente a IPC asíncrono. ^{[ 21 ]}

Dado que la comunicación entre procesos síncrona (IPC) bloquea a la primera parte hasta que la otra esté lista, su uso sin restricciones podría provocar fácilmente interbloqueos . Además, un cliente podría fácilmente lanzar un ataque de denegación de servicio contra un servidor enviando una solicitud y sin intentar recibir la respuesta. Por lo tanto, la IPC síncrona debe proporcionar un mecanismo para evitar bloqueos indefinidos. Muchos microkernels ofrecen tiempos de espera en las llamadas IPC, lo que limita el tiempo de bloqueo. En la práctica, elegir valores de tiempo de espera adecuados es difícil, y los sistemas casi inevitablemente utilizan tiempos de espera infinitos para los clientes y cero para los servidores. En consecuencia, la tendencia es no proporcionar tiempos de espera arbitrarios, sino solo un indicador que señale que la IPC debe fallar inmediatamente si el interlocutor no está listo. Este enfoque ofrece, en la práctica, la posibilidad de elegir entre dos valores de tiempo de espera: cero e infinito. Las versiones recientes de L4 y MINIX han seguido este camino (las versiones anteriores de L4 utilizaban tiempos de espera). QNX evita el problema al requerir que el cliente especifique el búfer de respuesta como parte de la llamada de envío de mensajes. Cuando el servidor responde, el kernel copia los datos al búfer del cliente, sin tener que esperar a que el cliente reciba la respuesta explícitamente. ^{[ 22 ]}

Los servidores de microkernel son esencialmente programas demonio como cualquier otro, con la diferencia de que el kernel les otorga a algunos privilegios para interactuar con partes de la memoria física que, de otro modo, estarían restringidas para la mayoría de los programas. Esto permite que algunos servidores, en particular los controladores de dispositivos, interactúen directamente con el hardware.

Un conjunto básico de servidores para un microkernel de propósito general incluye servidores de sistema de archivos, servidores de controladores de dispositivos, servidores de red, servidores de visualización y servidores de interfaz de usuario. Este conjunto de servidores (tomado de QNX ) proporciona, a grandes rasgos, los mismos servicios que ofrece un kernel monolítico de Unix . Los servidores necesarios se inician al arrancar el sistema y proporcionan servicios, como acceso a archivos, redes y dispositivos, a los programas de aplicación habituales. Al ejecutarse estos servidores en el entorno de una aplicación de usuario, el desarrollo de servidores es similar al desarrollo de aplicaciones convencionales, en lugar del proceso de compilación y arranque necesario para el desarrollo del kernel.

Además, muchos fallos pueden corregirse simplemente deteniendo y reiniciando el servidor , lo cual no sería factible si fuera necesario reiniciar todo el núcleo. Sin embargo, parte del estado del sistema se pierde con el fallo del servidor, por lo que este enfoque requiere que las aplicaciones puedan gestionar el fallo. Un buen ejemplo es un servidor responsable de las conexiones TCP/IP : si se reinicia este servidor, las aplicaciones experimentarán una pérdida de conexión, algo normal en un sistema en red. Para otros servicios, el fallo es menos frecuente y puede requerir cambios en el código de la aplicación. Para QNX, la capacidad de reinicio se ofrece como parte del QNX High Availability Toolkit. ^{[ 23 ]}

Los controladores de dispositivos suelen realizar acceso directo a memoria (DMA) y, por lo tanto, pueden escribir en ubicaciones arbitrarias de la memoria física, incluidas diversas estructuras de datos del núcleo. Por consiguiente, es fundamental confiar en dichos controladores. Existe la creencia errónea de que esto implica que deben formar parte del núcleo. De hecho, un controlador no es inherentemente más o menos confiable por el hecho de formar parte del núcleo.

Si bien ejecutar un controlador de dispositivo en el espacio de usuario no reduce necesariamente el daño que puede causar un controlador defectuoso, en la práctica es beneficioso para la estabilidad del sistema en presencia de controladores con errores (en lugar de controladores maliciosos): las violaciones de acceso a la memoria por parte del código del controlador (en lugar del dispositivo) aún pueden ser detectadas por el hardware de administración de memoria. Además, muchos dispositivos no son compatibles con DMA; sus controladores pueden volverse no confiables al ejecutarlos en el espacio de usuario. Recientemente, un número creciente de computadoras incorpora IOMMU , muchas de las cuales pueden usarse para restringir el acceso de un dispositivo a la memoria física. ^{[ 24 ]} Esto también permite que los controladores en modo de usuario se vuelvan no confiables.

Los controladores en modo usuario son anteriores a los microkernels. El Michigan Terminal System (MTS), en 1967, admitía controladores en espacio de usuario (incluido su soporte para el sistema de archivos), siendo el primer sistema operativo diseñado con esa capacidad. ^{[ 25 ]} Históricamente, los controladores no representaban un problema, ya que el número de dispositivos era pequeño y, en cualquier caso, confiable, por lo que tenerlos en el kernel simplificaba el diseño y evitaba posibles problemas de rendimiento. Esto condujo al estilo tradicional de controlador en el kernel de Unix, ^{[ 26 ]} Linux y Windows NT. Con la proliferación de diversos tipos de periféricos, la cantidad de código de controlador aumentó y, en los sistemas operativos modernos, domina al kernel en tamaño de código.

Dado que un microkernel debe permitir la creación de servicios de sistema operativo arbitrarios sobre él, debe proporcionar cierta funcionalidad básica. Como mínimo, esto incluye:

• Algunos mecanismos para gestionar los espacios de direcciones , necesarios para administrar la protección de la memoria.
• Algún tipo de abstracción de ejecución para gestionar la asignación de CPU, normalmente hilos o activaciones del planificador.
• Comunicación entre procesos , necesaria para invocar servidores que se ejecutan en sus propios espacios de direcciones.

Este diseño minimalista fue impulsado por Nucleus de Brinch Hansen y el hipervisor de la máquina virtual de IBM . Posteriormente, se formalizó en el principio de minimalismo de Liedtke :

Un concepto se tolera dentro del microkernel solo si trasladarlo fuera del kernel, es decir, permitir implementaciones competitivas, impediría la implementación de la funcionalidad requerida del sistema. ^{[ 20 ]}

Todo lo demás se puede hacer en un programa en modo de usuario, aunque los controladores de dispositivos implementados como programas de usuario pueden requerir, en algunas arquitecturas de procesador, privilegios especiales para acceder al hardware de E/S.

Relacionada con el principio de minimalidad, y de igual importancia para el diseño de microkernels, se encuentra la separación entre mecanismo y política , que permite la construcción de sistemas arbitrarios sobre un kernel mínimo. Ninguna política integrada en el kernel puede ser sobrescrita a nivel de usuario y, por lo tanto, limita la generalidad del microkernel. ^{[ 16 ]} La política implementada en los servidores a nivel de usuario puede modificarse reemplazando los servidores (o permitiendo que la aplicación elija entre servidores competidores que ofrecen servicios similares).

Para mejorar la eficiencia, la mayoría de los microkernels contienen planificadores y gestionan temporizadores, lo que contraviene el principio de minimalidad y el principio de separación entre política y mecanismo.

El arranque de un sistema basado en microkernel requiere controladores de dispositivos , que no forman parte del kernel. Normalmente, esto significa que se empaquetan con el kernel en la imagen de arranque, y el kernel admite un protocolo de arranque que define cómo se localizan e inician los controladores; este es el procedimiento de arranque tradicional de los microkernels L4 . Algunos microkernels, como LynxOS y el Minix original , simplifican esto colocando algunos controladores clave dentro del kernel (en contra del principio de minimalidad). Algunos incluso incluyen un sistema de archivos en el kernel para simplificar el arranque. Un sistema basado en microkernel puede arrancar mediante un cargador de arranque compatible con arranque múltiple. Estos sistemas suelen cargar servidores enlazados estáticamente para realizar un arranque inicial o montar una imagen del sistema operativo para continuar el arranque.

Un componente clave de un microkernel es un buen sistema IPC y un diseño de gestor de memoria virtual que permita implementar de forma segura el manejo de fallos de página y el intercambio de memoria en servidores en modo usuario. Dado que todos los servicios son ejecutados por programas en modo usuario, es fundamental contar con medios de comunicación eficientes entre programas, mucho más que en los kernels monolíticos. El diseño del sistema IPC es determinante para el éxito o el fracaso de un microkernel. Para ser eficaz, el sistema IPC no solo debe tener una baja sobrecarga, sino también interactuar correctamente con la planificación de la CPU.

En la mayoría de los procesadores convencionales, obtener un servicio es inherentemente más costoso en un sistema basado en microkernel que en un sistema monolítico. ^{[ 16 ]} En el sistema monolítico, el servicio se obtiene mediante una única llamada al sistema, que requiere dos cambios de modo (cambios del anillo del procesador o modo de CPU ). En el sistema basado en microkernel, el servicio se obtiene enviando un mensaje IPC a un servidor y obteniendo el resultado en otro mensaje IPC del servidor. Esto requiere un cambio de contexto si los controladores se implementan como procesos, o una llamada a función si se implementan como procedimientos. Además, pasar datos reales al servidor y viceversa puede generar una sobrecarga de copia adicional, mientras que en un sistema monolítico el kernel puede acceder directamente a los datos en los búferes del cliente.

Por lo tanto, el rendimiento es un problema potencial en los sistemas de microkernel, y los microkernels de primera generación, como Mach y ChorusOS, de hecho tuvieron un rendimiento deficiente. ^{[ 19 ]} Sin embargo, Jochen Liedtke demostró que los problemas de rendimiento de Mach eran el resultado de un diseño e implementación deficientes, específicamente la excesiva huella de caché de Mach . ^{[ 20 ]} Liedtke demostró con su propio microkernel L4 que, mediante un diseño e implementación cuidadosos, y especialmente siguiendo el principio de minimalidad, los costos de IPC podían reducirse en más de un orden de magnitud en comparación con Mach. El rendimiento de IPC de L4 sigue siendo insuperable en una variedad de arquitecturas. ^{[ 27 ] [ 28 ] [ 29 ]}

Si bien estos resultados demuestran que el bajo rendimiento de los sistemas basados ​​en microkernels de primera generación no es representativo de los kernels de segunda generación como L4, esto no constituye una prueba de que los sistemas basados ​​en microkernels puedan construirse con un buen rendimiento. Se ha demostrado que un servidor Linux monolítico portado a L4 presenta solo un pequeño porcentaje de sobrecarga con respecto a Linux nativo. ^{[ 30 ]} Sin embargo, un sistema de un solo servidor de este tipo presenta pocas, o ninguna, de las ventajas que se supone que los microkernels proporcionan al estructurar la funcionalidad del sistema operativo en servidores separados.

Existen varios sistemas multiservidor comerciales, en particular los sistemas en tiempo real QNX e Integrity . No se ha publicado ninguna comparación exhaustiva del rendimiento de estos sistemas multiservidor con respecto a los sistemas monolíticos. Además, el rendimiento no parece ser la principal preocupación de estos sistemas comerciales, que en cambio priorizan tiempos de respuesta rápidos y fiables para el manejo de interrupciones (QNX) y la simplicidad en aras de la robustez. Un intento de crear un sistema operativo multiservidor de alto rendimiento fue el proyecto IBM Sawmill Linux. ^{[ 31 ]} Sin embargo, este proyecto nunca se completó.

Mientras tanto, se ha demostrado que los controladores de dispositivos a nivel de usuario pueden alcanzar un rendimiento similar al de los controladores del núcleo, incluso para dispositivos de alto rendimiento y con muchas interrupciones como Gigabit Ethernet. ^{[ 32 ]} Esto parece implicar que son posibles los sistemas multiservidor de alto rendimiento.

Los beneficios de seguridad de los microkernels se han discutido con frecuencia. ^{[ 33 ] [ 34 ]} En el contexto de la seguridad, el principio de minimalidad de los microkernels es, según algunos, una consecuencia directa del principio de mínimo privilegio , según el cual todo el código debe tener solo los privilegios necesarios para proporcionar la funcionalidad requerida. La minimalidad exige que la base de computación confiable (TCB) de un sistema se mantenga mínima. Dado que el kernel (el código que se ejecuta en el modo privilegiado del hardware) tiene acceso no verificado a cualquier dato y, por lo tanto, puede violar su integridad o confidencialidad, el kernel siempre forma parte de la TCB. Minimizarla es natural en un diseño orientado a la seguridad.

En consecuencia, los diseños de microkernel se han utilizado para sistemas diseñados para aplicaciones de alta seguridad, incluidos KeyKOS , EROS y sistemas militares. De hecho, los criterios comunes (CC) en el nivel de garantía más alto ( Nivel de Garantía de Evaluación (EAL) 7) tienen un requisito explícito de que el objetivo de la evaluación sea "simple", un reconocimiento de la imposibilidad práctica de establecer una verdadera confiabilidad para un sistema complejo. Nuevamente, el término "simple" es engañoso y está mal definido. Al menos, los Criterios de Evaluación de Sistemas Informáticos Confiables del Departamento de Defensa introdujeron una terminología algo más precisa en las clases B3/A1:

El TCB deberá implementar mecanismos de protección completos y conceptualmente sencillos, con una semántica definida con precisión. Se dedicará una parte importante de la ingeniería del sistema a minimizar la complejidad del TCB, así como a excluir del mismo aquellos módulos que no sean críticos para la protección.

En 2018, un artículo presentado en la Conferencia de Sistemas de Asia-Pacífico afirmó que los microkernels eran demostrablemente más seguros que los kernels monolíticos tras investigar todas las vulnerabilidades críticas ( CVE) publicadas para el kernel de Linux en ese momento. El estudio concluyó que el 40 % de los problemas no podrían ocurrir en absoluto en un microkernel formalmente verificado, y que solo el 4 % de los problemas permanecerían sin mitigar en un sistema de este tipo. ^{[ 35 ]}

Los trabajos más recientes sobre microkernels se han centrado en las especificaciones formales de la API del kernel y en las pruebas formales de las propiedades de seguridad y la corrección de la implementación de la API. El primer ejemplo de esto es una prueba matemática de los mecanismos de confinamiento en EROS, basada en un modelo simplificado de la API de EROS. ^{[ 36 ]} Más recientemente (en 2007) se realizó un conjunto completo de pruebas verificadas por máquina de las propiedades del modelo de protección de seL4 , una versión de L4. ^{[ 37 ]}

Esto ha dado lugar a lo que se conoce como microkernels de tercera generación , ^{[ 38 ]} caracterizados por una API orientada a la seguridad con acceso a recursos controlado por capacidades , virtualización como una preocupación de primera clase, enfoques novedosos para la gestión de recursos del kernel, ^{[ 39 ]} y un objetivo de diseño de idoneidad para el análisis formal , además del objetivo habitual de alto rendimiento. Ejemplos de ello son Coyotos , seL4 , Nova, ^{[ 40 ] [ 41 ]} Redox y Fiasco.OC. ^{[ 40 ] [ 42 ]}

En el caso de seL4, se ha logrado una verificación formal completa de la implementación, ^{[ 38 ]} es decir, una prueba matemática de que la implementación del núcleo es consistente con su especificación formal. Esto proporciona una garantía de que las propiedades probadas sobre la API se cumplen realmente para el núcleo real, un grado de seguridad que va incluso más allá de CC EAL7. A esto le siguieron pruebas de las propiedades de aplicación de seguridad de la API y una prueba que demuestra que el código binario ejecutable es una traducción correcta de la implementación en C, sacando al compilador del TCB. En conjunto, estas pruebas establecen una prueba de extremo a extremo de las propiedades de seguridad del núcleo. ^{[ 43 ]}

Algunos ejemplos de microkernels son:

• AmigaOS
• Sistema operativo Amoeba
• BlackBerry QNX
• Genode
• HarmonyOS ( HarmonyOS 5 )
• LiteOS (descontinuado)
• HelenOS
• Horizon ( software para Nintendo 3DS y Nintendo Switch )
• La familia de microkernels L4
• Mach
• Mac OS 7 a Mac OS 9 ( nanokernel de Mac OS )
• Minix (abandonado)
• Midori (descontinuado)
• Sistema operativo fantasma
• Sistema operativo Qubes
• Redox
• Symbian (descontinuado)
• SymbOS
• HiloX
• Circón

El término nanokernel o picokernel se refería históricamente a:

• Un kernel donde la cantidad total de código del kernel, es decir, el código que se ejecuta en el modo privilegiado del hardware, es muy pequeña. El término picokernel se usaba a veces para enfatizar aún más su pequeño tamaño. El término nanokernel fue acuñado por Jonathan S. Shapiro en el artículo «The KeyKOS NanoKernel Architecture» . Fue una respuesta sarcástica a Mach , que se autodenominaba microkernel, mientras que Shapiro lo consideraba monolítico, esencialmente desestructurado y más lento que los sistemas que pretendía reemplazar. La posterior reutilización y respuesta al término, incluyendo la creación de picokernel, sugiere que el punto se pasó por alto en gran medida. Tanto nanokernel como picokernel han llegado a significar lo mismo que el término microkernel.
• Una capa de virtualización situada debajo de un sistema operativo, que más correctamente se denomina hipervisor .
• Una capa de abstracción de hardware que forma la parte de nivel más bajo de un núcleo, a veces utilizada para proporcionar funcionalidad en tiempo real a sistemas operativos normales, como Adeos. ^{[ 44 ]}

También existe al menos un caso en el que el término nanokernel no se refiere a un kernel pequeño, sino a uno que admite una resolución de reloj de nanosegundos . ^{[ 45 ]}

• Módulo del kernel cargable
• Microservicios
• Debate Tanenbaum-Torvalds
• Unikernel
• Entorno múltiple y en tiempo real

• Artículos científicos sobre microkernels (en CiteSeerX ), entre los que se incluyen:
  • Hildebrand, Dan (1992). «Una visión general de la arquitectura de QNX». Actas del Taller sobre Micro-kernels y Otras Arquitecturas de Kernel . págs. 113–126 . CiteSeerX 10.1.1.459.4481 . ISBN   1-880446-42-1.– la referencia básica de QNX.
  • Tanenbaum, A.; Herder, J.; Bos, H. (mayo de 2006). "¿Podemos hacer que los sistemas operativos sean fiables y seguros?" . Computer . 39 (5): 44– 51. Bibcode : 2006Compr..39e..44T . doi : 10.1109/MC.2006.156 . S2CID 99779. Archivado del original el 21 de junio de 2017. Recuperado el 3 de abril de 2020 . -la referencia básica y fiable.
  • Black, DL; Golub, DB; Julin, DP; Rashid, RF; Draves, RP; Dean, RW; Forin, A.; Barrera, J.; Tokuda, H.; Malan, G.; Bohman, D. (marzo de 1992). "Arquitectura de sistemas operativos de microkernel y Mach". Journal of Information Processing . 14 (4).– la referencia básica de Mach.
• * Varhol, Peter D. (enero de 1994). "Los pequeños núcleos alcanzan un gran éxito" . Byte . Archivado del original el 7 de marzo de 2006. Recuperado el 20 de septiembre de 2017 .Evaluación del estado actual y futuro de los sistemas operativos basados ​​en microkernels a enero de 1994.
• Página de MicroKernel del Repositorio de Patrones de Portland
• El debate Tanenbaum-Torvalds
  • El debate Tanenbaum-Torvalds, 29 de enero de 1992
  • Tanenbaum, AS "¿ Podemos lograr que los sistemas operativos sean fiables y seguros? ".
  • Torvalds, L. Linus Torvalds vuelve a hablar de los microkernels, 9 de mayo de 2006.
  • Shapiro, J. " Desmintiendo lo último de Linus ".
  • Tanenbaum, AS " Debate Tanenbaum-Torvalds: Parte II ".