En informática , un microkernel (a menudo abreviado como μ-kernel ) es la cantidad casi mínima de software que puede proporcionar los mecanismos necesarios para implementar un sistema operativo (SO). Estos mecanismos incluyen gestión del espacio de direcciones de bajo nivel , gestión de subprocesos y 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, lo que generalmente se denomina modo supervisor o kernel . Las funciones tradicionales del sistema operativo, como controladores de dispositivos , pilas de protocolos y sistemas de archivos , normalmente se eliminan del propio microkernel y, en cambio, se ejecutan en el espacio del usuario . [1]
En términos del tamaño del código fuente, los microkernels suelen ser más pequeños que los monolíticos . El microkernel MINIX 3 , por ejemplo, tiene sólo 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 mandato en la empresa informática danesa Regnecentralen , donde dirigió los esfuerzos de desarrollo de software para la computadora RC 4000. [3] En 1967, Regnecentralen estaba instalando un prototipo RC 4000 en la planta de fertilizantes Zakłady Azotowe Puławy en Polonia. La computadora utilizaba un pequeño sistema operativo en tiempo real adaptado a las necesidades de la planta. Brinch Hansen y su equipo comenzaron a preocuparse 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 comenzaron a investigar formas novedosas y más generales de crear software para el RC 4000. [4] En 1969, su esfuerzo resultó en la finalización del sistema de multiprogramación 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í a la vez. Además, implementó la programación de intervalos de tiempo de programas ejecutados en paralelo, el inicio y control de la ejecución del programa a solicitud de otros programas en ejecución y el inicio de transferencias de datos hacia o desde periféricos. Además de estos mecanismos elementales, no tenía una estrategia incorporada para la ejecución del programa y la asignación de recursos. Esta estrategia iba a ser implementada mediante una jerarquía de programas en ejecución en los que los procesos principales tenían control total sobre los procesos secundarios y actuaban como sus sistemas operativos. [5] [6]
Siguiendo el trabajo de Brinch Hansen, los microkernels se han desarrollado desde los años 1970. [7] El término microkernel apareció por primera vez a más tardar en 1981. [8] Los microkernels fueron concebidos como una respuesta a los cambios en el mundo de la informática y a varios desafíos para adaptar los " mono-kernels " existentes a estos nuevos sistemas. Todo el tiempo se desarrollaban nuevos controladores de dispositivos, pilas de protocolos, sistemas de archivos y otros sistemas de bajo nivel. Este código normalmente estaba ubicado en el núcleo monolítico y, por lo tanto, requería un trabajo considerable y una gestión cuidadosa del código. Los microkernels se desarrollaron con la idea de que todos estos servicios se implementarían como programas de espacio de usuario, como cualquier otro, permitiendo trabajar en ellos de forma monolítica e iniciarlos y detenerlos como cualquier otro programa. Esto no sólo permitiría trabajar más fácilmente con estos servicios, sino que también separaría el código del núcleo para permitir su ajuste sin preocuparse por efectos secundarios no deseados. Además, permitiría "construir" sistemas operativos completamente nuevos sobre un núcleo común, lo que ayudaría a la investigación de sistemas operativos.
Los micronúcleos fueron un tema muy candente en la década de 1980, cuando se introdujeron las primeras redes de área local utilizables. [ cita necesaria ] . 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 la memoria, considerada en otros aspectos una falla, permitió que este núcleo tuviera un rendimiento de paso de mensajes muy alto porque no necesitaba copiar datos mientras intercambiaba mensajes entre programas en el espacio de usuario. [9]
Los mismos mecanismos que permitieron que el kernel se distribuyera en el espacio del usuario también permitieron que el sistema se distribuyera 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 fue una importante línea de investigación hasta finales de los años 1990. [ cita necesaria ] Sin embargo, durante este tiempo la velocidad de las computadoras creció enormemente en relación con los sistemas de redes, y las desventajas en el rendimiento llegaron a superar las ventajas en términos de desarrollo. [ cita necesaria ]
Se hicieron muchos intentos para adaptar los sistemas existentes para que tuvieran un mejor rendimiento, pero la sobrecarga siempre fue considerable y la mayoría de estos esfuerzos requirieron que los programas del espacio de usuario volvieran al núcleo. Para el año 2000, la mayoría de los esfuerzos a gran escala del kernel Mach habían terminado, aunque macOS de Apple , lanzado en 2001, todavía usa un kernel híbrido llamado XNU , que combina un kernel Mach OSF/1 muy modificado (híbrido) ( kernel OSFMK 7.3) con código de BSD UNIX, [10] [11] y este kernel también se usa en iOS , tvOS y watchOS . Windows NT , comenzando con NT 3.1 y continuando con Windows 11 , utiliza un diseño de kernel híbrido. A partir de 2012 , GNU Hurd basado en Mach también es funcional y se incluye en las versiones de prueba de Arch Linux y Debian .[actualizar]
Aunque los principales trabajos sobre micronúcleos habían terminado en gran medida, los experimentadores continuaron con el desarrollo. [ cita necesaria ] Desde entonces se ha demostrado que muchos de los problemas de rendimiento de diseños anteriores no eran una limitación fundamental del concepto, sino que se debían al deseo del diseñador de utilizar sistemas de propósito único para implementar tantos de estos servicios como fuera posible. [ cita necesaria ] El uso de un enfoque más pragmático del problema, incluido el código ensamblador y la dependencia del procesador para hacer cumplir conceptos normalmente admitidos en el software, condujo a una nueva serie de micronúcleos con un rendimiento dramáticamente mejorado.
Los microkernels están estrechamente relacionados con los exokernels . [12] También tienen mucho en común con los hipervisores , [13] pero estos últimos no pretenden ser minimalistas y están especializados en soportar máquinas virtuales ; El micronúcleo L4 se utiliza con frecuencia en una capacidad de hipervisor.
Los primeros núcleos de los sistemas operativos eran bastante pequeños, en parte porque la memoria de la computadora era limitada. A medida que crecía la capacidad de las computadoras, también crecía la cantidad de dispositivos que el núcleo tenía que controlar. A lo largo de la historia temprana de Unix , los núcleos eran generalmente pequeños, aunque contenían varios 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 ya no estuvo limitado por la arquitectura del hardware y los núcleos comenzaron a crecer.
Berkeley Software Distribution (BSD) de Unix inició la era de los núcleos más grandes. Además de operar un sistema básico que consta de CPU, discos e impresoras, BSD agregó un sistema de red TCP/IP completo y una serie de dispositivos "virtuales" que permitieron que los programas existentes funcionaran "invisiblemente" a través de la red. Este crecimiento continuó durante muchos años, dando lugar a núcleos con millones de líneas de código fuente . Como resultado de este crecimiento, los kernels eran propensos a sufrir errores y se volvieron cada vez más difíciles de mantener.
El micronúcleo estaba destinado a abordar este crecimiento de núcleos y las dificultades resultantes. En teoría, el diseño del microkernel permite una gestión más sencilla del código debido a su división en servicios de espacio de usuario . Esto también permite una mayor seguridad y estabilidad resultante 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 del búfer , solo se dañará la memoria del servicio de red, dejando el resto del sistema aún funcional.
La comunicación entre procesos (IPC) es cualquier mecanismo que permite que procesos separados se comuniquen entre sí, generalmente mediante el envío de mensajes . La memoria compartida es, estrictamente definida, también un mecanismo de comunicación entre procesos, pero la abreviatura IPC generalmente se refiere únicamente al paso de mensajes, y es esto último lo que es particularmente relevante para los microkernels. IPC permite que el sistema operativo se construya a partir de una serie de programas más pequeños llamados servidores, que son utilizados por otros programas en el sistema, invocados a través de IPC. La mayor parte o todo el soporte para hardware periférico se maneja de esta manera, con servidores para controladores de dispositivos, pilas de protocolos de red , sistemas de archivos, gráficos, etc.
IPC puede ser sincrónico o asincrónico. La IPC asíncrona es análoga a la comunicación de red: el remitente envía un mensaje y continúa ejecutándolo. El receptor verifica ( encuesta ) la disponibilidad del mensaje o recibe una alerta a través de algún mecanismo de notificación. El IPC asíncrono requiere que el kernel mantenga buffers y colas para mensajes y se ocupe de los desbordamientos del buffer; también requiere una doble copia de los mensajes (del remitente al kernel y del kernel al receptor). En la IPC sincrónica, la primera parte (remitente o receptor) bloquea hasta que la otra parte esté lista para realizar la IPC. No requiere almacenamiento en búfer ni copias múltiples, pero el encuentro implícito puede complicar la programación. La mayoría de los programadores prefieren el envío y la recepción asíncronos.
Los micronúcleos de primera generación normalmente soportaban IPC tanto síncrono como asíncrono, y adolecían de un rendimiento IPC deficiente. Jochen Liedtke consideró que el diseño y la implementación de los mecanismos de IPC eran la razón subyacente de este pobre desempeño. En su micronúcleo L4 fue pionero en métodos que redujeron los costos de IPC en un orden de magnitud . [14] Estos incluyen una llamada al sistema IPC que admite una operación de envío y recepción, haciendo que todo el IPC sea sincrónico y pasando la mayor cantidad de datos posible en los 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) desde el remitente directamente al receptor. Si, como en L4, parte o todo el mensaje se pasa en registros, esto transfiere la parte del mensaje en el registro sin ninguna copia. Además, se evita la sobrecarga de invocar el planificador; Esto es especialmente beneficioso en el caso común en el que un cliente que invoca un servidor utiliza IPC en forma de llamada a procedimiento remoto (RPC). Otra optimización, llamada programación diferida , evita atravesar colas de programación durante IPC al dejar los subprocesos que se bloquean durante IPC en la cola de listos. Una vez que se invoca el programador, mueve dichos subprocesos a la cola de espera adecuada. Como en muchos casos un hilo se desbloquea antes de la siguiente invocación del programador, este enfoque ahorra mucho trabajo. Desde entonces, QNX y MINIX 3 han adoptado enfoques similares . [ cita necesaria ]
En una serie de experimentos, Chen y Bershad compararon los ciclos de memoria por instrucción (MCPI) del monolítico Ultrix con los del microkernel Mach combinado con un servidor Unix 4.3BSD ejecutándose en el espacio del 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. [15] Más tarde, Liedtke refinó los resultados de Chen y Bershad al hacer una observación de que la mayor parte de la diferencia entre Ultrix y Mach MCPI fue causada por errores de capacidad de caché y concluyó que reducir drásticamente el conjunto de trabajo de caché de un microkernel resolverá el problema. [dieciséis]
En un sistema cliente-servidor, la mayor parte de la comunicación es esencialmente síncrona, incluso si se utilizan primitivas asíncronas, ya que la operación típica es que un cliente invoca a un servidor y luego espera una respuesta. Como también se presta a una implementación más eficiente, la mayoría de los microkernels generalmente siguieron el ejemplo de L4 y solo proporcionaron una primitiva IPC sincrónica. El IPC asincrónico podría implementarse en la parte superior mediante el uso de subprocesos auxiliares. Sin embargo, la experiencia ha demostrado que la utilidad del IPC síncrono es dudosa: el IPC síncrono fuerza un diseño de subprocesos múltiples en sistemas que de otro modo serían simples, con las consiguientes complejidades de sincronización. Además, una invocación de servidor tipo RPC secuencializa al cliente y al servidor, lo que debería 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 asincrónica para soportar mejor la comunicación asincrónica. Este mecanismo similar a una señal no transporta datos y, por lo tanto, no requiere almacenamiento en búfer por parte del núcleo. Al tener dos formas de IPC, no obstante han violado el principio de minimidad. Otras versiones de L4 han cambiado completamente a IPC asíncrono. [17]
Como la IPC sincrónica bloquea a la primera parte hasta que la otra esté lista, el uso sin restricciones podría conducir fácilmente a interbloqueos. Además, un cliente podría fácilmente montar un ataque de denegación de servicio en un servidor enviando una solicitud y nunca intentando recibir la respuesta. Por lo tanto, la IPC sincrónica debe proporcionar un medio para evitar el bloqueo indefinido. Muchos microkernels proporcionan tiempos de espera en las llamadas de IPC, lo que limita el tiempo de bloqueo. En la práctica, elegir valores de tiempo de espera razonables es difícil y los sistemas casi inevitablemente utilizan tiempos de espera infinitos para los clientes y cero tiempos de espera para los servidores. Como consecuencia, la tendencia es no proporcionar tiempos de espera arbitrarios, sino sólo una bandera que indique que el IPC debería fallar inmediatamente si el socio no está listo. Este enfoque proporciona efectivamente la posibilidad de elegir entre dos valores de tiempo de espera de cero e infinito. Las versiones recientes de L4 y MINIX han seguido este camino (las versiones anteriores de L4 usaban 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. [18]
Los servidores Microkernel son esencialmente programas demonio como cualquier otro, excepto que el kernel otorga a algunos de ellos privilegios para interactuar con partes de la memoria física que de otro modo estarían fuera del alcance de 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 sistemas de archivos, servidores de controladores de dispositivos, servidores de redes, servidores de visualización y servidores de dispositivos de interfaz de usuario. Este conjunto de servidores (extraídos de QNX ) proporciona aproximadamente el conjunto de servicios que ofrece un núcleo monolítico Unix . Los servidores necesarios se inician al iniciar el sistema y brindan servicios, como acceso a archivos, redes y dispositivos, a programas de aplicaciones comunes. Con dichos servidores ejecutándose en el entorno de una aplicación de usuario, el desarrollo del servidor es similar al desarrollo de aplicaciones ordinarias, en lugar del proceso de compilación y arranque necesario para el desarrollo del kernel.
Además, muchos "fallos" se pueden corregir simplemente deteniendo y reiniciando el servidor . Sin embargo, parte del estado del sistema se pierde cuando el servidor falla, por lo que este enfoque requiere que las aplicaciones hagan frente a la falla. Un buen ejemplo es un servidor responsable de las conexiones TCP/IP : si se reinicia este servidor, las aplicaciones experimentarán una conexión "perdida", algo normal en un sistema en red. Para otros servicios, la falla es menos esperada y puede requerir cambios en el código de la aplicación. Para QNX, la capacidad de reinicio se ofrece como kit de herramientas de alta disponibilidad de QNX. [19]
Los controladores de dispositivos frecuentemente realizan acceso directo a la memoria (DMA) y, por lo tanto, pueden escribir en ubicaciones arbitrarias de la memoria física, incluidas varias estructuras de datos del kernel. Por lo tanto, se debe confiar en estos conductores. Es un error común pensar que esto significa que deben ser parte del núcleo. De hecho, un controlador no es inherentemente más o menos confiable por ser parte del núcleo.
Si bien ejecutar un controlador de dispositivo en el espacio del usuario no necesariamente reduce el daño que puede causar un controlador que se comporta mal, en la práctica es beneficioso para la estabilidad del sistema en presencia de controladores defectuosos (en lugar de maliciosos): violaciones de acceso a la memoria por parte del propio código del controlador ( a diferencia del dispositivo) todavía puede ser capturado por el hardware de administración de memoria. Además, muchos dispositivos no son compatibles con DMA y sus controladores pueden dejar de ser confiables ejecutándolos en el espacio del usuario. Recientemente, un número cada vez mayor de computadoras cuentan con IOMMU , muchas de las cuales pueden usarse para restringir el acceso de un dispositivo a la memoria física. [20] Esto también permite que los controladores en modo de usuario dejen de ser confiables.
Los controladores en modo de usuario en realidad son anteriores a los microkernels. El Michigan Terminal System (MTS), en 1967, admitía controladores de espacio de usuario (incluido su soporte de sistema de archivos), el primer sistema operativo diseñado con esa capacidad. [21] Históricamente, los controladores eran un problema menor, ya que la cantidad de dispositivos era pequeña y confiable de todos modos, por lo que tenerlos en el kernel simplificó el diseño y evitó posibles problemas de rendimiento. Esto llevó al estilo tradicional de controlador en el kernel de Unix, [22] Linux y Windows NT. Con la proliferación de varios tipos de periféricos, la cantidad de código de controlador aumentó y en los sistemas operativos modernos domina el núcleo en tamaño de código.
Como un microkernel debe permitir construir servicios arbitrarios del sistema operativo encima, debe proporcionar alguna funcionalidad básica. Como mínimo, esto incluye:
Este diseño minimalista fue iniciado por Nucleus de Brinch Hansen y el hipervisor de VM de IBM . Desde entonces se ha formalizado en el principio de minimalidad de Liedtke :
Un concepto se tolera dentro del micronúcleo sólo si moverlo fuera del núcleo, es decir, permitir implementaciones competitivas, impediría la implementación de la funcionalidad requerida del sistema. [dieciséis]
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 privilegios especiales en algunas arquitecturas de procesador para acceder al hardware de E/S.
Relacionada con el principio de minimalidad, e igualmente importante para el diseño de micronúcleos, está la separación de mecanismo y política ; es lo que permite la construcción de sistemas arbitrarios sobre un núcleo mínimo. Cualquier política integrada en el kernel no se puede sobrescribir a nivel de usuario y, por lo tanto, limita la generalidad del microkernel. [12] La política implementada en los servidores a nivel de usuario se puede cambiar reemplazando los servidores (o dejando que la aplicación elija entre servidores competidores que ofrecen servicios similares).
Para lograr eficiencia, la mayoría de los micronúcleos contienen programadores y administran temporizadores, en violación del principio de minimalidad y el principio de separación entre políticas y mecanismos.
El inicio ( arranque ) de un sistema basado en microkernel requiere controladores de dispositivo , que no forman parte del kernel. Normalmente, esto significa que están empaquetados con el kernel en la imagen de arranque, y el kernel admite un protocolo de arranque que define cómo se ubican e inician los controladores; Este es el procedimiento de arranque tradicional de los micronúcleos L4 . Algunos microkernels simplifican esto colocando algunos controladores clave dentro del kernel (en violación del principio de minimalidad), LynxOS y el Minix original son ejemplos. 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 vinculados estáticamente para realizar un arranque inicial o montar una imagen del sistema operativo para continuar con el arranque.
Un componente clave de un microkernel es un buen sistema IPC y un diseño de administrador de memoria virtual que permita implementar el manejo e intercambio de fallas de página en servidores en modo de usuario de manera segura. Dado que todos los servicios son realizados por programas en modo de usuario, son esenciales medios eficientes de comunicación entre programas, mucho más que en los núcleos monolíticos. El diseño del sistema IPC hace o deshace un micronúcleo. Para ser eficaz, el sistema IPC no sólo debe tener una sobrecarga baja, sino también interactuar bien con la programació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. [12] En el sistema monolítico, el servicio se obtiene mediante una única llamada al sistema, que requiere dos cambios de modo (cambios de anillo del procesador o de 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 adicional de copia, mientras que en un sistema monolítico el núcleo puede acceder directamente a los datos en los buffers del cliente.
Por lo tanto, el rendimiento es un problema potencial en los sistemas de micronúcleo. La experiencia con microkernels de primera generación como Mach y ChorusOS demostró que los sistemas basados en ellos funcionaban muy mal. [15] 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 . [16] Liedtke demostró con su propio micronúcleo L4 que mediante un diseño e implementación cuidadosos, y especialmente siguiendo el principio de minimalidad, los costos de IPC podrían reducirse en más de un orden de magnitud en comparación con Mach. El rendimiento IPC de L4 sigue siendo insuperable en una variedad de arquitecturas. [23] [24] [25]
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 ninguna 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 sólo un pequeño porcentaje de sobrecarga sobre Linux nativo. [26] Sin embargo, un sistema de servidor único de este tipo presenta pocas, o ninguna, de las ventajas que se supone que proporcionan los microkernels al estructurar la funcionalidad del sistema operativo en servidores separados.
Existen varios sistemas comerciales multiservidor, en particular los sistemas en tiempo real QNX e Integrity . No se ha publicado ninguna comparación exhaustiva del rendimiento en relación con los sistemas monolíticos para esos sistemas multiservidor. Además, el rendimiento no parece ser la preocupación primordial para esos sistemas comerciales, que en cambio enfatizan tiempos de respuesta de manejo de interrupciones rápidos y confiables (QNX) y la simplicidad en aras de la robustez. Un intento de construir un sistema operativo multiservidor de alto rendimiento fue el proyecto IBM Sawmill Linux. [27] Sin embargo, este proyecto nunca se completó.
Mientras tanto, se ha demostrado que los controladores de dispositivos a nivel de usuario pueden acercarse al rendimiento de los controladores internos incluso para dispositivos de alto rendimiento y altas interrupciones como Gigabit Ethernet. [28] Esto parece implicar que los sistemas multiservidor de alto rendimiento son posibles.
Los beneficios de seguridad de los microkernels se han discutido con frecuencia. [29] [30] En el contexto de la seguridad, el principio de minimalidad de los microkernels es, según algunos han argumentado, una consecuencia directa del principio de privilegio mínimo , según el cual todo código debe tener sólo los privilegios necesarios para proporcionar la funcionalidad requerida. La minimalidad requiere que la base informática confiable (TCB) de un sistema se mantenga al mínimo. Como el kernel (el código que se ejecuta en el modo privilegiado del hardware) tiene acceso no autorizado a cualquier dato y, por lo tanto, puede violar su integridad o confidencialidad, el kernel siempre es parte del TCB. Minimizarlo es natural en un diseño basado en 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. Una vez más, 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 palabrería algo más precisa en las clases B3/A1:
"La TCB [implementará] mecanismos de protección completos, conceptualmente simples, con una semántica definida con precisión. La ingeniería de sistemas significativa se dirigirá a minimizar la complejidad de la TCB, así como a excluir de la TCB aquellos módulos que no sean críticos para la protección".
— Criterios de evaluación de sistemas informáticos confiables del Departamento de Defensa
En 2018, un artículo presentado en la Conferencia de Sistemas de Asia y el Pacífico afirmó que los microkernels eran demostrablemente más seguros que los kernels monolíticos al investigar todos los CVE críticos publicados 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 micronúcleo verificado formalmente, y solo el 4% de los problemas permanecerían completamente sin mitigar en dicho sistema. [31]
El trabajo más reciente sobre microkernels se ha centrado en especificaciones formales de la API del kernel y 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. [32] 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. [33]
Esto ha llevado a lo que se conoce como microkernels de tercera generación , [34] caracterizados por una API orientada a la seguridad con acceso a recursos controlado por capacidades , la virtualización como una preocupación de primera clase, enfoques novedosos para la gestión de recursos del kernel, [35] y un objetivo de diseño de idoneidad para el análisis formal , además del objetivo habitual de alto rendimiento. Algunos ejemplos son Coyotos, seL4 , Nova, [36] [37] Redox y Fiasco.OC. [36] [38]
En el caso de seL4, se ha logrado una verificación formal completa de la implementación, [34] 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 realmente se mantienen para el núcleo real, un grado de seguridad que va más allá incluso de CC EAL7. 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 de C, sacando el compilador del TCB. En conjunto, estas pruebas establecen una prueba de extremo a extremo de las propiedades de seguridad del kernel. [39]
Algunos ejemplos de microkernels son:
El término nanokernel o picokernel históricamente hacía referencia a:
También hay al menos un caso en el que el término nanokernel se utiliza para referirse no a un núcleo pequeño, sino a uno que admite una resolución de reloj de nanosegundos . [40]
{{cite book}}: Mantenimiento CS1: falta el editor de la ubicación ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace )-la referencia básica confiable.{{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace )– la referencia básica de Mach.