Núcleo (sistema operativo)

Una consideración importante en el diseño de un núcleo es el soporte que proporciona para la protección contra fallos ( tolerancia a fallos ) y contra comportamientos maliciosos ( seguridad ). Estos dos aspectos no suelen distinguirse claramente, y la adopción de esta distinción en el diseño del núcleo conlleva el rechazo de una estructura jerárquica para la protección . ^{[ 5 ]}

Los mecanismos o políticas proporcionados por el núcleo se pueden clasificar según varios criterios, entre ellos:

• ya sean estáticas (que se aplican en tiempo de compilación ) o dinámicas (que se aplican en tiempo de ejecución );
• ya sean preventivas o posteriores a la detección;
• ya sean compatibles con hardware o basadas en lenguaje;
• ya sea que se trate más de un mecanismo abierto o de una política vinculante;
• de acuerdo con los principios de protección que satisfacen (por ejemplo, Denning ^{[ 11 ] [ 12 ]} );
• y muchos más.

El soporte para dominios de protección jerárquicos ^{[ 13 ]} se implementa normalmente utilizando modos de CPU .

Muchos núcleos implementan "capacidades", es decir, objetos proporcionados al código de usuario que permiten un acceso limitado a un objeto subyacente gestionado por el núcleo. Un ejemplo común es la gestión de archivos: un archivo es una representación de información almacenada en un dispositivo de almacenamiento permanente. El núcleo puede realizar diversas operaciones, como leer, escribir, eliminar o ejecutar, pero una aplicación de usuario solo puede tener permiso para realizar algunas de ellas (por ejemplo, solo puede leer el archivo). Una implementación común consiste en que el núcleo proporcione a la aplicación un objeto (normalmente denominado "identificador de archivo") sobre el cual la aplicación puede invocar operaciones, cuya validez el núcleo verifica en el momento de la solicitud. Este sistema puede extenderse para abarcar todos los objetos gestionados por el núcleo, e incluso objetos proporcionados por otras aplicaciones de usuario.

Una forma eficiente y sencilla de proporcionar soporte de hardware para capacidades es delegar a la unidad de gestión de memoria (MMU) la responsabilidad de verificar los derechos de acceso para cada acceso a la memoria, un mecanismo llamado direccionamiento basado en capacidades . ^{[ 14 ]} La mayoría de las arquitecturas de computadoras comerciales carecen de dicho soporte de MMU para capacidades; el proyecto Capability Hardware Enhanced RISC Instructions (CHERI) está desarrollando mecanismos basados ​​en capacidades para varias arquitecturas.

Un enfoque alternativo consiste en simular capacidades utilizando dominios jerárquicos comúnmente compatibles. En este enfoque, cada objeto protegido debe residir en un espacio de direcciones al que la aplicación no tenga acceso; el núcleo también mantiene una lista de capacidades en dicha memoria. Cuando una aplicación necesita acceder a un objeto protegido por una capacidad, realiza una llamada al sistema y el núcleo comprueba si la capacidad de la aplicación le otorga permiso para realizar la acción solicitada; si es así, realiza el acceso por ella (ya sea directamente o delegando la solicitud a otro proceso de nivel de usuario). El coste de rendimiento del cambio de espacio de direcciones limita la practicidad de este enfoque en sistemas con interacciones complejas entre objetos, pero se utiliza en los sistemas operativos actuales para objetos a los que no se accede con frecuencia o que no se espera que tengan un rendimiento rápido. ^{[ 15 ] [ 16 ]}

Si el firmware no admite mecanismos de protección, es posible simular la protección a un nivel superior, por ejemplo, simulando capacidades mediante la manipulación de tablas de páginas , pero esto tiene implicaciones en el rendimiento. ^{[ 17 ]} Sin embargo, la falta de soporte de hardware puede no ser un problema para los sistemas que optan por utilizar protección basada en lenguaje. ^{[ 18 ]}

Una decisión importante en el diseño del núcleo es la elección de los niveles de abstracción donde se deben implementar los mecanismos y políticas de seguridad. Los mecanismos de seguridad del núcleo desempeñan un papel fundamental en el soporte de la seguridad en niveles superiores. ^{[ 14 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ]}

Un enfoque consiste en utilizar el firmware y el soporte del kernel para la tolerancia a fallos (véase más arriba), y construir la política de seguridad para comportamientos maliciosos sobre esa base (añadiendo características como mecanismos criptográficos cuando sea necesario), delegando cierta responsabilidad al compilador . Los enfoques que delegan la aplicación de la política de seguridad al compilador o al nivel de la aplicación se denominan a menudo seguridad basada en el lenguaje .

La falta de muchos mecanismos de seguridad críticos en los sistemas operativos convencionales actuales impide la implementación de políticas de seguridad adecuadas en el nivel de abstracción de la aplicación . ^{[ 19 ]} De hecho, una idea errónea común en seguridad informática es que cualquier política de seguridad puede implementarse en una aplicación independientemente del soporte del núcleo. ^{[ 19 ]}

Según los desarrolladores de Mars Research Group, la falta de aislamiento es uno de los principales factores que socavan la seguridad del kernel. ^{[ 23 ]} Proponen su marco de aislamiento de controladores para la protección, principalmente en el kernel de Linux. ^{[ 24 ] [ 25 ]}

Edsger Dijkstra demostró que, desde un punto de vista lógico, las operaciones atómicas de bloqueo y desbloqueo que operan sobre semáforos binarios son primitivas suficientes para expresar cualquier funcionalidad de cooperación de procesos. ^{[ 27 ]} No obstante, este enfoque generalmente se considera deficiente en términos de seguridad y eficiencia, mientras que un enfoque de paso de mensajes es más flexible. ^{[ 28 ]} También existen otros enfoques (de nivel inferior o superior), y muchos núcleos modernos brindan soporte para sistemas como memoria compartida y llamadas a procedimientos remotos .

La idea de un núcleo donde los dispositivos de E/S se manejan uniformemente con otros procesos, como procesos cooperativos paralelos, fue propuesta e implementada por primera vez por Brinch Hansen (aunque ideas similares se sugirieron en 1967 ^{[ 29 ] [ 30 ]} ). En la descripción de Hansen, los procesos "comunes" se denominan procesos internos , mientras que los dispositivos de E/S se denominan procesos externos . ^{[ 28 ]}

De forma similar a la memoria física, permitir que las aplicaciones accedan directamente a los puertos y registros del controlador puede provocar un mal funcionamiento del mismo o un fallo del sistema. Por ello, dependiendo de la complejidad del dispositivo, algunos dispositivos pueden ser sorprendentemente complejos de programar y utilizar varios controladores diferentes. Debido a esto, es importante proporcionar una interfaz más abstracta para gestionar el dispositivo. Esta interfaz normalmente la proporciona un controlador de dispositivo o una capa de abstracción de hardware. Con frecuencia, las aplicaciones requerirán acceso a estos dispositivos. El núcleo debe mantener la lista de estos dispositivos consultando al sistema de alguna manera. Esto puede hacerse a través de la BIOS o a través de uno de los diversos buses del sistema (como PCI/PCIE o USB). Tomando como ejemplo un controlador de vídeo, cuando una aplicación solicita una operación en un dispositivo, como mostrar un carácter, el núcleo debe enviar esta solicitud al controlador de vídeo activo. El controlador de vídeo, a su vez, debe ejecutar esta solicitud. Este es un ejemplo de comunicación entre procesos (IPC).

En un núcleo monolítico, todos los servicios del sistema operativo forman parte del núcleo y se ejecutan en modo núcleo, residiendo así en la misma área de memoria. Este enfoque proporciona un acceso al hardware potente y eficiente. El desarrollador de UNIX, Ken Thompson, afirmó que, en su opinión, es más fácil implementar un núcleo monolítico. ^{[ 37 ]} Las principales desventajas de los núcleos monolíticos son las dependencias entre los componentes del sistema ( por ejemplo , un error en un controlador de dispositivo podría provocar el fallo de todo el sistema) y la dificultad de mantenimiento de núcleos grandes. Thompson también señaló que un núcleo monolítico puede convertirse rápidamente en un caos al modificarse. ^{[ 37 ]}  

Los núcleos monolíticos, tradicionalmente utilizados por sistemas operativos tipo Unix , contienen todas las funciones principales del sistema operativo y los controladores de dispositivos . Un núcleo monolítico es un único programa que contiene todo el código necesario para realizar cualquier tarea relacionada con el núcleo. Cada componente al que un programa debe acceder y que no puede ubicarse en una biblioteca se encuentra en el espacio del núcleo, incluyendo controladores, planificadores , gestión de memoria , sistemas de archivos y pilas de red . Se proporcionan numerosas llamadas al sistema a las aplicaciones para que puedan acceder a todos estos servicios. Un núcleo monolítico, si bien inicialmente se carga con subsistemas que podrían no ser necesarios, puede optimizarse hasta alcanzar una velocidad igual o superior a la de un núcleo diseñado específicamente para el hardware, aunque resulta más relevante en un sentido general.

Los núcleos monolíticos modernos, como el núcleo de Linux , el núcleo de FreeBSD , el núcleo de AIX , el núcleo de HP-UX y el núcleo de Solaris , todos los cuales pertenecen a la categoría de sistemas operativos tipo Unix, admiten módulos de núcleo cargables , lo que permite cargar módulos en el núcleo en tiempo de ejecución, facilitando la ampliación de las capacidades del núcleo según sea necesario, al tiempo que ayuda a minimizar la cantidad de código que se ejecuta en el espacio del núcleo.

La mayor parte del trabajo en el núcleo monolítico se realiza mediante llamadas al sistema . Estas son interfaces, generalmente organizadas en una estructura tabular, que acceden a algún subsistema dentro del núcleo, como las operaciones de disco. Básicamente, las llamadas se realizan dentro de los programas y una copia verificada de la solicitud se pasa a través de la llamada al sistema. Por lo tanto, no hay que recorrer mucha distancia. El núcleo monolítico de Linux puede hacerse extremadamente pequeño no solo por su capacidad de cargar módulos dinámicamente, sino también por su facilidad de personalización. De hecho, existen algunas versiones lo suficientemente pequeñas como para caber junto con una gran cantidad de utilidades y otros programas en un solo disquete y aún así proporcionar un sistema operativo completamente funcional (una de las más populares es muLinux ). Esta capacidad de miniaturizar su núcleo también ha llevado a un rápido crecimiento en el uso de Linux en sistemas embebidos .

Este tipo de núcleos consta de las funciones principales del sistema operativo y los controladores de dispositivos, con la capacidad de cargar módulos en tiempo de ejecución. Proporcionan abstracciones ricas y potentes del hardware subyacente. Ofrecen un pequeño conjunto de abstracciones de hardware simples y utilizan aplicaciones llamadas servidores para proporcionar más funcionalidad. Este enfoque particular define una interfaz virtual de alto nivel sobre el hardware, con un conjunto de llamadas al sistema para implementar servicios del sistema operativo, como la gestión de procesos , la concurrencia y la gestión de memoria, en varios módulos que se ejecutan en modo supervisor. Este diseño tiene varias fallas y limitaciones:

• Programar en el kernel puede ser complicado, en parte porque no se pueden usar bibliotecas comunes (como una libc completa ) y porque se necesita un depurador a nivel de código fuente como gdb . A menudo es necesario reiniciar el equipo. Esto no es solo una cuestión de comodidad para los desarrolladores. Cuando la depuración es más difícil, y a medida que las dificultades aumentan, es más probable que el código contenga más errores.
• Los errores en una parte del núcleo tienen fuertes efectos secundarios; dado que cada función del núcleo tiene todos los privilegios, un error en una función puede corromper las estructuras de datos de otra parte del núcleo totalmente ajena, o de cualquier programa en ejecución.
• Los núcleos suelen volverse muy grandes y difíciles de mantener.
• Aunque los módulos que dan servicio a estas operaciones estén separados del conjunto, la integración del código es estrecha y difícil de realizar correctamente.
• Dado que los módulos se ejecutan en el mismo espacio de direcciones , un error puede provocar la caída de todo el sistema.

Microkernel (también abreviado μK o uK) es el término que describe un enfoque de diseño de sistemas operativos en el que la funcionalidad del sistema se traslada del "kernel" tradicional a un conjunto de "servidores" que se comunican a través de un kernel "mínimo", dejando lo mínimo posible en el "espacio del sistema" y lo máximo posible en el "espacio de usuario". Un microkernel diseñado para una plataforma o dispositivo específico solo tendrá lo necesario para su funcionamiento. El enfoque del microkernel consiste en definir una abstracción simple sobre el hardware, con un conjunto de primitivas o llamadas al sistema para implementar servicios mínimos del sistema operativo, como la gestión de memoria , la multitarea y la comunicación entre procesos . Otros servicios, incluidos los que normalmente proporciona el kernel, como la comunicación en red , se implementan en programas del espacio de usuario, denominados servidores . Los microkernels son más fáciles de mantener que los kernels monolíticos, pero la gran cantidad de llamadas al sistema y cambios de contexto puede ralentizar el sistema, ya que suelen generar más sobrecarga que las llamadas a funciones simples.

Solo las partes que realmente requieren estar en un modo privilegiado se encuentran en el espacio del kernel , como la comunicación entre procesos (IPC), un planificador básico o primitivas de planificación, la gestión básica de memoria y las primitivas básicas de E/S. Muchas partes críticas ahora se ejecutan en el espacio de usuario, incluyendo el planificador completo, la gestión de memoria, los sistemas de archivos y las pilas de red . Los microkernels se inventaron como reacción al diseño tradicional de kernel "monolítico", en el que toda la funcionalidad del sistema se colocaba en un programa estático que se ejecutaba en un modo "sistema" especial del procesador. En el microkernel, solo las tareas más fundamentales se realizan a este nivel, como poder acceder a parte (no necesariamente a todo) del hardware, gestionar la memoria y coordinar el paso de mensajes entre los procesos. Algunos sistemas que utilizan microkernels son QNX y GNU Hurd . En el caso de QNX y GNU Hurd, las sesiones de usuario pueden ser instantáneas completas del propio sistema, o "vistas", como se las denomina. La esencia misma de la arquitectura del microkernel ilustra algunas de sus ventajas:

• Más fácil de mantener
• Los parches se pueden probar en una instancia separada y luego intercambiarlos para que tomen el control de una instancia de producción.
• El desarrollo es rápido y el software nuevo se puede probar sin necesidad de reiniciar el núcleo.
• Mayor persistencia en general: si una instancia falla, a menudo es posible sustituirla por una réplica operativa.

La mayoría de los microkernels utilizan un sistema de paso de mensajes para gestionar las solicitudes entre servidores. Este sistema suele operar mediante puertos dentro del microkernel. Por ejemplo, si se solicita más memoria, se abre un puerto en el microkernel y se transmite la solicitud. Una vez dentro del microkernel, los pasos son similares a las llamadas al sistema. El objetivo era aportar modularidad a la arquitectura del sistema, lo que resultaría en un sistema más limpio, fácil de depurar o modificar dinámicamente, personalizable según las necesidades del usuario y con un mayor rendimiento. Los microkernels forman parte de sistemas operativos como GNU Hurd , MINIX , MkLinux , QNX y Redox OS .

Aunque los microkernels son muy pequeños por sí mismos, en combinación con todo el código auxiliar necesario, suelen ser más grandes que los kernels monolíticos. Los defensores de los kernels monolíticos también señalan que la estructura de dos niveles de los sistemas de microkernels, en la que la mayor parte del sistema operativo no interactúa directamente con el hardware, genera un coste considerable en términos de eficiencia del sistema. Este tipo de kernels normalmente solo proporciona los servicios mínimos, como la definición de espacios de direcciones de memoria , la comunicación entre procesos (IPC) y la gestión de procesos . Otras funciones, como la ejecución de procesos de hardware, no son gestionadas directamente por los microkernels. Los defensores de los microkernels señalan que los kernels monolíticos tienen la desventaja de que un error en el kernel puede provocar el fallo de todo el sistema. Sin embargo, con un microkernel, si un proceso del kernel falla, aún es posible evitar el fallo del sistema en su conjunto simplemente reiniciando el servicio que causó el error.

Otros servicios proporcionados por el núcleo, como la conectividad de red, se implementan en programas del espacio de usuario denominados servidores . Los servidores permiten modificar el sistema operativo simplemente iniciando y deteniendo programas. Por ejemplo, en una máquina sin conectividad de red, el servidor de red no se inicia. La necesidad de acceder al núcleo y transferir datos entre las distintas aplicaciones y servidores genera una sobrecarga que perjudica la eficiencia de los micronúcleos en comparación con los núcleos monolíticos.

Sin embargo, el microkernel presenta algunas desventajas. Algunas de ellas son:

• Mayor huella de memoria en ejecución
• Se requiere más software para la interfaz, por lo que existe la posibilidad de una pérdida de rendimiento.
• Los errores de mensajería pueden ser más difíciles de corregir debido al recorrido más largo que deben realizar, en comparación con la copia única en un núcleo monolítico.
• La gestión de procesos en general puede ser muy complicada.

Las desventajas de los microkernels dependen en gran medida del contexto. Por ejemplo, funcionan bien para sistemas pequeños, de propósito único (y críticos), ya que si no se necesitan ejecutar muchos procesos, las complicaciones de la gestión de procesos se reducen considerablemente.

Un microkernel permite implementar la parte restante del sistema operativo como programas que se ejecutan en modo usuario, y el uso de diferentes sistemas operativos sobre el mismo kernel sin modificar. También es posible alternar dinámicamente entre sistemas operativos y tener más de uno activo simultáneamente. ^{[ 28 ]}

A medida que crece el núcleo de la computadora, también crece el tamaño y la vulnerabilidad de su base de computación confiable , además de su huella de memoria . Esto se mitiga en cierta medida perfeccionando un sistema de memoria virtual , pero no todas las arquitecturas de computadoras tienen soporte para memoria virtual. ^{[ f ]} Para reducir la huella del núcleo, se debe realizar una edición extensa para eliminar cuidadosamente el código innecesario, lo cual puede ser muy difícil con interdependencias no obvias entre partes de un núcleo con millones de líneas de código.

A principios de la década de 1990, debido a las diversas deficiencias de los núcleos monolíticos frente a los micronúcleos, prácticamente todos los investigadores de sistemas operativos consideraban obsoletos los núcleos monolíticos. Como resultado, el diseño de Linux como un núcleo monolítico en lugar de un micronúcleo fue el tema de un famoso debate entre Linus Torvalds y Andrew Tanenbaum . ^{[ 38 ]} Ambos lados del argumento presentado en el debate Tanenbaum-Torvalds tienen su mérito .

Actuación

Los núcleos monolíticos están diseñados para tener todo su código en el mismo espacio de direcciones ( espacio del núcleo ), lo que algunos desarrolladores argumentan que es necesario para aumentar el rendimiento del sistema. ^{[ 39 ]} Algunos desarrolladores también sostienen que los sistemas monolíticos son extremadamente eficientes si están bien escritos. ^{[ 39 ]} El modelo monolítico tiende a ser más eficiente ^{[ 40 ]} mediante el uso de memoria compartida del núcleo, en lugar del sistema IPC más lento de los diseños de micronúcleos, que normalmente se basa en el paso de mensajes .

El rendimiento de los microkernels fue deficiente tanto en la década de 1980 como a principios de la de 1990. ^{[ 41 ] [ 42 ]} Los estudios que midieron empíricamente el rendimiento de estos microkernels no analizaron las razones de dicha ineficiencia. ^{[ 41 ]} Las explicaciones de estos datos se dejaron en manos del "folclore" , con la suposición de que se debían a la mayor frecuencia de cambios del "modo kernel" al "modo usuario", a la mayor frecuencia de comunicación entre procesos y a la mayor frecuencia de cambios de contexto . ^{[ 41 ]}

De hecho, como se intuyó en 1995, las razones del bajo rendimiento de los microkernels podrían haber sido: (1) una ineficiencia real del enfoque de microkernel en su conjunto , (2) los conceptos particulares implementados en esos microkernels y (3) la implementación particular de esos conceptos. Por lo tanto, quedaba por estudiar si la solución para construir un microkernel eficiente consistía, a diferencia de los intentos anteriores, en aplicar las técnicas de construcción correctas. ^{[ 41 ]}

Por otro lado, la arquitectura de dominios de protección jerárquica que lleva al diseño de un núcleo monolítico ^{[ 36 ]} tiene una desventaja de rendimiento significativa cada vez que hay una interacción entre diferentes niveles de protección (es decir, cuando un proceso tiene que manipular una estructura de datos tanto en "modo usuario" como en "modo supervisor"), ya que esto requiere la copia de mensajes por valor . ^{[ 43 ]}

Los núcleos híbridos se utilizan en algunos sistemas operativos comerciales, incluyendo la mayoría de las versiones de Microsoft Windows hasta la fecha ( NT 3.1 , NT 3.5 , NT 3.51 , NT 4.0 , 2000 , XP , Vista , 7 , 8 , 8.1 , 10 y 11 ). macOS de Apple utiliza un núcleo híbrido llamado XNU , que se basa en el código del núcleo Mach de OSF/1 (OSFMK 7.3) ^{[ 44 ]} y el núcleo monolítico de FreeBSD . Los núcleos híbridos son similares a los micronúcleos, excepto que incluyen código adicional en el espacio del núcleo para aumentar el rendimiento. Estos núcleos representan un compromiso que fue implementado por algunos desarrolladores para acomodar las principales ventajas tanto de los núcleos monolíticos como de los micronúcleos. Este tipo de núcleos son extensiones de los micronúcleos con algunas propiedades de los núcleos monolíticos. A diferencia de los núcleos monolíticos, este tipo de núcleos no pueden cargar módulos en tiempo de ejecución por sí mismos. Esto implica ejecutar algunos servicios (como la pila de red o el sistema de archivos ) en el espacio del kernel para reducir la sobrecarga de rendimiento de un microkernel tradicional, pero seguir ejecutando el código del kernel (como los controladores de dispositivos ) como servidores en el espacio de usuario.

Muchos núcleos tradicionalmente monolíticos admiten módulos de núcleo cargables . El más conocido de estos núcleos es el núcleo Linux . El núcleo modular esencialmente puede tener partes integradas en el binario del núcleo principal o binarios que se cargan en memoria bajo demanda. Un módulo con código contaminado puede desestabilizar un núcleo en ejecución. Por el contrario, es posible escribir un controlador para un micronúcleo en un espacio de memoria completamente separado y probarlo antes de su lanzamiento. Cuando se carga un módulo de núcleo, accede al espacio de memoria de la parte monolítica agregando lo que necesita, lo que abre la puerta a una posible contaminación. Algunas ventajas del núcleo modular (o híbrido) son:

• Tiempo de desarrollo más rápido para controladores que pueden operar desde módulos internos. No se requiere reiniciar para realizar pruebas (siempre que el kernel no esté desestabilizado).
• Capacidad bajo demanda frente a la necesidad de recompilar todo el núcleo para incorporar nuevos controladores o subsistemas.
• Integración más rápida de tecnología de terceros (relacionada con el desarrollo, pero pertinente en sí misma).

Los módulos, por lo general, se comunican con el núcleo mediante una interfaz de módulo. Esta interfaz es generalizada (aunque específica para cada sistema operativo), por lo que no siempre es posible usar módulos. A menudo, los controladores de dispositivos requieren mayor flexibilidad que la que ofrece la interfaz de módulo. En esencia, se trata de dos llamadas al sistema y, con frecuencia, las comprobaciones de seguridad que en el núcleo monolítico solo se realizan una vez ahora pueden requerir dos. Algunas de las desventajas del enfoque modular son:

• Con más interfaces por las que pasar, existe la posibilidad de que aumenten los errores (lo que implica más fallos de seguridad).
• El mantenimiento de los módulos puede resultar confuso para algunos administradores al lidiar con problemas como las diferencias de símbolos.

Un nanokernel delega prácticamente todos los servicios , incluso los más básicos como los controladores de interrupciones o el temporizador , a los controladores de dispositivos para que el requisito de memoria del kernel sea aún menor que el de un microkernel tradicional. ^{[ 45 ]}  

Los exokernels representan un enfoque aún experimental para el diseño de sistemas operativos. Se diferencian de otros tipos de kernels en que limitan su funcionalidad a la protección y multiplexación del acceso al hardware en bruto, sin proporcionar abstracciones de hardware sobre las cuales desarrollar aplicaciones. Esta separación entre la protección y la gestión del hardware permite a los desarrolladores de aplicaciones determinar la forma más eficiente de aprovechar el hardware disponible para cada programa específico.

Los exokernels son, en sí mismos, extremadamente pequeños. No obstante, vienen acompañados de sistemas operativos de biblioteca (véase también unikernel ), que proporcionan a los desarrolladores de aplicaciones las funcionalidades de un sistema operativo convencional. Una gran ventaja de los sistemas basados ​​en exokernels es que pueden incorporar múltiples sistemas operativos de biblioteca, cada uno de los cuales exporta una API diferente ; por ejemplo, uno para el desarrollo de interfaces de usuario de alto nivel y otro para el control en tiempo real .

Un sistema operativo multikernel trata una máquina multinúcleo como una red de núcleos independientes, como si fuera un sistema distribuido . No asume memoria compartida, sino que implementa las comunicaciones entre procesos como paso de mensajes . ^{[ 46 ] [ 47 ]} Barrelfish fue el primer sistema operativo descrito como multikernel.

Estrictamente hablando, un sistema operativo (y, por lo tanto, un núcleo) no es necesario para que un ordenador funcione. Los programas pueden cargarse y ejecutarse directamente en la máquina "bare metal" , siempre que sus autores estén dispuestos a trabajar sin ninguna abstracción de hardware ni soporte de un sistema operativo. La mayoría de los primeros ordenadores funcionaban de esta manera durante las décadas de 1950 y principios de 1960, reiniciándose y recargándose entre la ejecución de diferentes programas. Con el tiempo, pequeños programas auxiliares, como cargadores de programas y depuradores, se dejaban en memoria entre ejecuciones o se cargaban desde la ROM . A medida que se desarrollaban, sentaron las bases de lo que se convertiría en los primeros núcleos de sistemas operativos. El enfoque "bare metal" todavía se utiliza hoy en día en algunas consolas de videojuegos y sistemas embebidos , ^{[ 48 ]} pero, en general, los ordenadores más modernos utilizan sistemas operativos y núcleos modernos.

En 1969, el sistema de multiprogramación RC 4000 introdujo la filosofía de diseño de sistemas de un pequeño núcleo "sobre el cual se podrían construir sistemas operativos para diferentes propósitos de manera ordenada", ^{[ 49 ]} lo que se denominaría el enfoque del microkernel.

En la década anterior a Unix , las computadoras habían aumentado enormemente en potencia , hasta el punto de que los operadores buscaban nuevas formas de lograr que la gente utilizara su tiempo libre en sus máquinas. Uno de los principales avances durante esta época fue el tiempo compartido , mediante el cual varios usuarios obtenían pequeñas porciones de tiempo de computadora, a una velocidad tal que parecía que cada uno estaba conectado a su propia máquina, más lenta. ^{[ 50 ]} 

El desarrollo de los sistemas de tiempo compartido generó varios problemas. Uno de ellos fue que los usuarios, especialmente en las universidades donde se desarrollaban estos sistemas, querían piratearlos para obtener más tiempo de CPU . Por esta razón, la seguridad y el control de acceso se convirtieron en un aspecto fundamental del proyecto Multics en 1965. ^{[ 51 ]} Otro problema persistente fue la gestión adecuada de los recursos informáticos: los usuarios pasaban la mayor parte del tiempo mirando la terminal y pensando en qué introducir en lugar de utilizar realmente los recursos del ordenador, y un sistema de tiempo compartido debería asignar el tiempo de CPU a un usuario activo durante estos periodos. Finalmente, los sistemas solían ofrecer una jerarquía de memoria de varias capas de profundidad, y la partición de este costoso recurso impulsó importantes avances en los sistemas de memoria virtual .

El Commodore Amiga se lanzó en 1985 y fue uno de los primeros —y sin duda el más exitoso— ordenadores domésticos en incorporar una arquitectura de núcleo avanzada. El componente ejecutivo del núcleo de AmigaOS, exec.library , utiliza un diseño de paso de mensajes de micronúcleo, pero existen otros componentes del núcleo, como graphics.library , que tienen acceso directo al hardware. No hay protección de memoria y el núcleo casi siempre se ejecuta en modo usuario. Solo se ejecutan acciones especiales en modo núcleo, y las aplicaciones en modo usuario pueden solicitar al sistema operativo que ejecute su código en modo núcleo.  

Durante la fase de diseño de Unix , los programadores decidieron modelar cada dispositivo de alto nivel como un archivo , porque creían que el propósito de la computación era la transformación de datos . ^{[ 52 ]}

Por ejemplo, las impresoras se representaban como un "archivo" en una ubicación conocida ; al copiar datos al archivo, se imprimían. Otros sistemas, para proporcionar una funcionalidad similar, tendían a virtualizar los dispositivos a un nivel inferior ; es decir, tanto los dispositivos como los archivos eran instancias de algún concepto de nivel inferior . La virtualización del sistema a nivel de archivo permitía a los usuarios manipular todo el sistema utilizando sus utilidades y conceptos de gestión de archivos existentes , simplificando enormemente el funcionamiento. Como extensión del mismo paradigma, Unix permite a los programadores manipular archivos mediante una serie de pequeños programas, utilizando el concepto de tuberías , lo que permitía a los usuarios completar operaciones por etapas, pasando un archivo a través de una cadena de herramientas específicas. Aunque el resultado final era el mismo, el uso de programas más pequeños de esta manera aumentaba drásticamente la flexibilidad, así como la facilidad de desarrollo y uso, permitiendo al usuario modificar su flujo de trabajo añadiendo o eliminando un programa de la cadena.  

En el modelo Unix, el sistema operativo consta de dos partes: primero, la enorme colección de programas de utilidad que impulsan la mayoría de las operaciones; segundo, el núcleo que ejecuta los programas. ^{[ 52 ]} Bajo Unix, desde el punto de vista de la programación, la distinción entre los dos es bastante delgada; el núcleo es un programa, que se ejecuta en modo supervisor, ^{[ g ]} que actúa como un cargador de programas y supervisor para los pequeños programas de utilidad que componen el resto del sistema, y ​​para proporcionar servicios de bloqueo y E/S para estos programas; más allá de eso, el núcleo no intervenía en absoluto en el espacio de usuario .

Con el paso de los años, el modelo informático cambió, y el tratamiento que Unix daba a todo como un archivo o flujo de bytes dejó de ser tan universalmente aplicable como antes. Si bien una terminal podía tratarse como un archivo o un flujo de bytes, que se imprimía o desde el que se leía, no parecía aplicarse lo mismo a una interfaz gráfica de usuario . Las redes plantearon otro problema. Aunque la comunicación en red puede compararse con el acceso a archivos, la arquitectura de bajo nivel orientada a paquetes manejaba fragmentos discretos de datos y no archivos completos. A medida que aumentaba la capacidad de los ordenadores, Unix se fue llenando cada vez más de código. Esto se debe también a que la modularidad del núcleo de Unix es altamente escalable. ^{[ 53 ]} Mientras que los núcleos podían tener 100 000 líneas de código en los años setenta y ochenta, núcleos como Linux , o sucesores modernos de Unix como GNU , tienen más de 13 millones de líneas. ^{[ 54 ]}

Los derivados modernos de Unix generalmente se basan en núcleos monolíticos de carga de módulos. Ejemplos de esto son el núcleo Linux en muchas distribuciones de GNU , IBM AIX , así como los núcleos variantes de Berkeley Software Distribution como FreeBSD , DragonFly BSD , OpenBSD , NetBSD y macOS . Además de estas alternativas, los desarrolladores aficionados mantienen una comunidad activa de desarrollo de sistemas operativos , poblada por núcleos de aficionados escritos por ellos mismos que en su mayoría terminan compartiendo muchas características con los núcleos Linux, FreeBSD, DragonflyBSD, OpenBSD o NetBSD y/o siendo compatibles con ellos. ^{[ 55 ]}

Apple lanzó por primera vez su Mac OS clásico en 1984, incluido con su ordenador personal Macintosh . Apple pasó a un diseño de nanokernel en Mac OS 8.6. En contraste, el macOS moderno (originalmente llamado Mac OS X) se basa en Darwin , que utiliza un kernel híbrido llamado XNU , creado mediante la combinación del kernel 4.3BSD y el kernel Mach . ^{[ 56 ]}

Microsoft Windows se lanzó por primera vez en 1985 como un complemento para MS-DOS . Debido a su dependencia de otro sistema operativo, las primeras versiones de Windows, anteriores a Windows 95, se consideraban un entorno operativo (que no debe confundirse con un sistema operativo ). Esta línea de productos continuó evolucionando durante las décadas de 1980 y 1990, con la incorporación de la serie Windows 9x de direccionamiento de 32 bits y multitarea preventiva; pero finalizó con el lanzamiento de Windows Me en el año 2000.

Microsoft también desarrolló Windows NT , un sistema operativo con una interfaz muy similar, pero destinado a usuarios profesionales y empresariales. Esta línea comenzó con el lanzamiento de Windows NT 3.1 en 1993 y se introdujo para el público general con el lanzamiento de Windows XP en octubre de 2001, reemplazando a Windows 9x con un sistema operativo completamente diferente y mucho más sofisticado. Esta es la línea que continúa con Windows 11 .

La arquitectura del núcleo de Windows NT se considera un núcleo híbrido porque el propio núcleo contiene tareas como el Administrador de ventanas y los Administradores IPC, con un modelo de subsistema en capas cliente/servidor. ^{[ 57 ]} Fue diseñado como un micronúcleo modificado , ya que el núcleo de Windows NT estuvo influenciado por el micronúcleo Mach , pero no cumple con todos los criterios de un micronúcleo puro.

Un programa supervisor o supervisor es un programa informático , generalmente parte de un sistema operativo , que controla la ejecución de otras rutinas y regula la planificación del trabajo , las operaciones de entrada/salida , las acciones de error y funciones similares, y regula el flujo de trabajo en un sistema de procesamiento de datos .

Históricamente, este término se asociaba principalmente con la línea de sistemas operativos para mainframes de IBM , comenzando con OS/360 . En otros sistemas operativos, el supervisor se suele denominar núcleo.

En CP-40 y CP-67 , IBM abstrajo aún más el estado del supervisor del hardware, lo que dio como resultado un hipervisor que permitía la virtualización completa , es decir, la capacidad de ejecutar múltiples sistemas operativos en la misma máquina de forma totalmente independiente entre sí.

En la década de 1970, IBM actualizó CP/CMS para el System/370 bajo el nombre de Virtual Machine Facility/370 (VM/370). Por lo tanto, el primer sistema de este tipo se denominó Virtual Machine o VM .

Aunque Mach , desarrollado por Richard Rashid en la Universidad Carnegie Mellon , es el microkernel de propósito general más conocido, se han desarrollado otros microkernels con objetivos más específicos. La familia de microkernels L4 (principalmente el L3 y el L4) se creó para demostrar que los microkernels no son necesariamente lentos. ^{[ 58 ]} Implementaciones más recientes, como Fiasco y Pistachio, pueden ejecutar Linux junto a otros procesos L4 en espacios de direcciones separados. ^{[ 59 ] [ 60 ]}

Además, QNX es un microkernel que se utiliza principalmente en sistemas embebidos , ^{[ 61 ]} y el software de código abierto MINIX , aunque fue creado originalmente con fines educativos, ahora se centra en ser un sistema operativo de microkernel altamente confiable y autorreparable .