El kernel es un programa informático que se encuentra en el núcleo del sistema operativo de una computadora y generalmente tiene control total sobre todo lo que hay en el sistema. El kernel también es responsable de prevenir y mitigar conflictos entre diferentes procesos. [1] Es la parte del código del sistema operativo que siempre reside en la memoria [2] y facilita las interacciones entre los componentes de hardware y software. Un kernel completo controla todos los recursos de hardware (por ejemplo, E/S, memoria, criptografía) a través de controladores de dispositivos , arbitra conflictos entre procesos relacionados con dichos recursos y optimiza la utilización de recursos comunes, por ejemplo, uso de CPU y caché, sistemas de archivos y sockets de red. En la mayoría de los sistemas, el kernel es uno de los primeros programas que se cargan al inicio (después del gestor de arranque ). Maneja el resto del inicio, así como la memoria, los periféricos y las solicitudes de entrada/salida (E/S) del software , traduciéndolas en instrucciones de procesamiento de datos para la unidad central de procesamiento .
El código crítico del kernel generalmente se carga en un área separada de la memoria, que está protegida del acceso del software de aplicación u otras partes menos críticas del sistema operativo. El kernel realiza sus tareas, como ejecutar procesos, administrar dispositivos de hardware como el disco duro y manejar interrupciones, en este espacio protegido del kernel . Por el contrario, los programas de aplicación como navegadores, procesadores de texto o reproductores de audio o vídeo utilizan un área separada de memoria, el espacio de usuario . Esta separación evita que los datos del usuario y los datos del kernel interfieran entre sí y causen inestabilidad y lentitud, [1] además de evitar que las aplicaciones que funcionan mal afecten a otras aplicaciones o bloqueen todo el sistema operativo. Incluso en sistemas donde el kernel está incluido en los espacios de direcciones de la aplicación , se utiliza protección de memoria para evitar que aplicaciones no autorizadas modifiquen el kernel.
La interfaz del kernel es una capa de abstracción de bajo nivel . Cuando un proceso solicita un servicio del kernel, debe invocar una llamada al sistema , generalmente a través de una función contenedora .
Existen diferentes diseños de arquitectura de kernel. Los núcleos monolíticos se ejecutan completamente en un único espacio de direcciones con la CPU ejecutándose en modo supervisor , principalmente por motivos de velocidad. Los microkernels ejecutan la mayoría, pero no todos, sus servicios en el espacio del usuario, [3] como lo hacen los procesos del usuario, principalmente por su resiliencia y modularidad . [4] MINIX 3 es un ejemplo notable de diseño de microkernel. El kernel de Linux es monolítico y modular, ya que puede insertar y eliminar módulos del kernel cargables en tiempo de ejecución.
Este componente central de un sistema informático es responsable de ejecutar programas. El kernel asume la responsabilidad de decidir en cualquier momento cuál de los muchos programas en ejecución debe asignarse al procesador o procesadores.
La memoria de acceso aleatorio (RAM) se utiliza para almacenar tanto las instrucciones como los datos del programa. [a] Normalmente, ambos deben estar presentes en la memoria para que se ejecute un programa. A menudo, varios programas querrán acceder a la memoria y, con frecuencia, exigirán más memoria de la que la computadora tiene disponible. El kernel es responsable de decidir qué memoria puede usar cada proceso y determinar qué hacer cuando no hay suficiente memoria disponible.
Los dispositivos de E/S incluyen, entre otros, periféricos como teclados, ratones, unidades de disco, impresoras, dispositivos USB , adaptadores de red y dispositivos de visualización . El kernel proporciona métodos convenientes para que las aplicaciones utilicen estos dispositivos que normalmente el kernel abstrae para que las aplicaciones no necesiten conocer los detalles de su implementación.
Los aspectos clave necesarios en la gestión de recursos son definir el dominio de ejecución ( espacio de direcciones ) y el mecanismo de protección utilizado para mediar el acceso a los recursos dentro de un dominio. [5] Los kernels también proporcionan métodos de sincronización y comunicación entre procesos (IPC). Estas implementaciones pueden estar ubicadas dentro del propio kernel o el kernel también puede depender de otros procesos que esté ejecutando. Aunque el núcleo debe proporcionar IPC para brindar acceso a las funciones proporcionadas entre sí, los núcleos también deben proporcionar a los programas en ejecución un método para realizar solicitudes de acceso a estas funciones. El kernel también es responsable del cambio de contexto entre procesos o subprocesos.
El kernel tiene acceso completo a la memoria del sistema y debe permitir que los procesos accedan de forma segura a esta memoria cuando lo requieran. A menudo, el primer paso para hacer esto es el direccionamiento virtual , que generalmente se logra mediante paginación y/o segmentación . El direccionamiento virtual permite al núcleo hacer que una dirección física determinada parezca otra dirección, la dirección virtual. Los espacios de direcciones virtuales pueden ser diferentes para diferentes procesos; la memoria a la que accede un proceso en una dirección (virtual) particular puede ser una memoria diferente de la que accede otro proceso en la misma dirección. Esto permite que cada programa se comporte como si fuera el único (aparte del núcleo) en ejecución y, por lo tanto, evita que las aplicaciones fallen entre sí. [6]
En muchos sistemas, la dirección virtual de un programa puede hacer referencia a datos que no se encuentran actualmente en la memoria. La capa de indirección proporcionada por el direccionamiento virtual permite que el sistema operativo utilice otros almacenes de datos, como un disco duro , para almacenar lo que de otro modo tendría que permanecer en la memoria principal ( RAM ). Como resultado, los sistemas operativos pueden permitir que los programas utilicen más memoria de la que el sistema tiene físicamente disponible. Cuando un programa necesita datos que no están actualmente en la RAM, la CPU le indica al kernel que esto ha sucedido, y el kernel responde escribiendo el contenido de un bloque de memoria inactivo en el disco (si es necesario) y reemplazándolo con los datos solicitados por el programa. A continuación se puede reanudar el programa desde el punto en el que se detuvo. Este esquema se conoce generalmente como paginación de demanda .
El direccionamiento virtual también permite la creación de particiones virtuales de memoria en dos áreas inconexas, una reservada para el núcleo ( espacio del núcleo ) y la otra para las aplicaciones ( espacio de usuario ). El procesador no permite que las aplicaciones accedan a la memoria del kernel, lo que evita que una aplicación dañe el kernel en ejecución. Esta partición fundamental del espacio de memoria ha contribuido mucho a los diseños actuales de núcleos de propósito general reales y es casi universal en tales sistemas, aunque algunos núcleos de investigación (por ejemplo, Singularity ) adoptan otros enfoques.
Para realizar funciones útiles, los procesos necesitan acceso a los periféricos conectados a la computadora, los cuales son controlados por el kernel a través de controladores de dispositivos . Un controlador de dispositivo es un programa informático que encapsula, monitorea y controla un dispositivo de hardware (a través de su interfaz hardware/software (HSI)) en nombre del sistema operativo. Proporciona al sistema operativo una API, procedimientos e información sobre cómo controlar y comunicarse con una determinada pieza de hardware. Los controladores de dispositivos son una dependencia importante y vital para todos los sistemas operativos y sus aplicaciones. El objetivo del diseño de un controlador es la abstracción; La función del controlador es traducir las llamadas a funciones abstractas exigidas por el sistema operativo (llamadas de programación) en llamadas específicas del dispositivo. En teoría, un dispositivo debería funcionar correctamente con un controlador adecuado. Los controladores de dispositivos se utilizan, por ejemplo, para tarjetas de vídeo, tarjetas de sonido, impresoras, escáneres, módems y tarjetas de red.
A nivel de hardware, las abstracciones comunes de controladores de dispositivos incluyen:
Y a nivel de software, las abstracciones de controladores de dispositivos incluyen:
Por ejemplo, para mostrarle al usuario algo en la pantalla, una aplicación haría una solicitud al núcleo, que reenviaría la solicitud a su controlador de pantalla, que luego es responsable de trazar el carácter/píxel. [6]
Un kernel debe mantener una lista de dispositivos disponibles. Esta lista puede ser conocida de antemano (por ejemplo, en un sistema integrado donde el kernel se reescribirá si cambia el hardware disponible), configurada por el usuario (típico en PC más antiguas y en sistemas que no están diseñados para uso personal) o detectada por el sistema operativo en tiempo de ejecución (normalmente llamado plug and play ). En los sistemas plug-and-play, un administrador de dispositivos primero realiza un escaneo en diferentes buses periféricos , como Peripheral Component Interconnect (PCI) o Universal Serial Bus (USB), para detectar dispositivos instalados y luego busca los controladores apropiados.
Como la administración de dispositivos es un tema muy específico del sistema operativo , estos controladores se manejan de manera diferente según cada tipo de diseño de kernel, pero en cada caso, el kernel debe proporcionar la E/S para permitir que los controladores accedan físicamente a sus dispositivos a través de algún puerto o memoria. ubicación. Se deben tomar decisiones importantes al diseñar el sistema de administración de dispositivos, ya que en algunos diseños los accesos pueden implicar cambios de contexto , lo que hace que la operación requiera mucho uso de la CPU y provoque fácilmente una sobrecarga de rendimiento significativa. [ cita necesaria ]
En informática, una llamada al sistema es la forma en que un proceso solicita un servicio del núcleo de un sistema operativo que normalmente no tiene permiso para ejecutar. Las llamadas al sistema proporcionan la interfaz entre un proceso y el sistema operativo. La mayoría de las operaciones que interactúan con el sistema requieren permisos que no están disponibles para un proceso a nivel de usuario, por ejemplo, la E/S realizada con un dispositivo presente en el sistema, o cualquier forma de comunicación con otros procesos requiere el uso de llamadas al sistema.
Una llamada al sistema es un mecanismo que utiliza el programa de aplicación para solicitar un servicio del sistema operativo. Utilizan una instrucción de código de máquina que hace que el procesador cambie de modo. Un ejemplo sería del modo supervisor al modo protegido. Aquí es donde el sistema operativo realiza acciones como acceder a dispositivos de hardware o a la unidad de administración de memoria . Generalmente, el sistema operativo proporciona una biblioteca que se encuentra entre el sistema operativo y los programas de usuario normales. Generalmente es una biblioteca C como Glibc o API de Windows. La biblioteca maneja los detalles de bajo nivel de pasar información al kernel y cambiar al modo supervisor. Las llamadas al sistema incluyen cerrar, abrir, leer, esperar y escribir.
Para realizar realmente un trabajo útil, un proceso debe poder acceder a los servicios proporcionados por el kernel. Esto se implementa de manera diferente en cada kernel, pero la mayoría proporciona una biblioteca C o una API , que a su vez invoca las funciones del kernel relacionadas. [7]
El método para invocar la función del kernel varía de un kernel a otro. Si se utiliza el aislamiento de memoria, es imposible que un proceso de usuario llame al kernel directamente, porque eso sería una violación de las reglas de control de acceso del procesador. Algunas posibilidades son:
Una consideración importante en el diseño de un kernel es el soporte que brinda para la protección contra fallas ( tolerancia a fallas ) y contra comportamientos maliciosos ( seguridad ). Estos dos aspectos generalmente no se distinguen claramente y la adopción de esta distinción en el diseño del núcleo conduce al rechazo de una estructura jerárquica para la protección . [5]
Los mecanismos o políticas proporcionadas por el kernel se pueden clasificar según varios criterios, entre ellos: estáticos (aplicados en tiempo de compilación ) o dinámicos (aplicados en tiempo de ejecución ); preventiva o post-detección; según los principios de protección que satisfacen (por ejemplo, Denning [8] [9] ); si son compatibles con hardware o basados en lenguaje; si son más bien un mecanismo abierto o una política vinculante; y muchos más.
El soporte para dominios de protección jerárquica [10] normalmente se implementa utilizando modos de CPU .
Muchos núcleos proporcionan implementación de "capacidades", es decir, objetos que se proporcionan al código de usuario y que permiten un acceso limitado a un objeto subyacente administrado por el núcleo. Un ejemplo común es el manejo de archivos: un archivo es una representación de información almacenada en un dispositivo de almacenamiento permanente. El kernel puede realizar muchas operaciones diferentes, incluidas leer, escribir, eliminar o ejecutar, pero es posible que una aplicación de nivel de usuario solo pueda realizar algunas de estas operaciones (por ejemplo, es posible que solo se le permita leer el archivo). Una implementación común de esto es que el kernel proporcione un objeto a la aplicación (normalmente llamado "identificador de archivo") sobre el cual la aplicación puede invocar operaciones, cuya validez el kernel verifica en el momento en que se solicita la operación. Un sistema de este tipo puede ampliarse para abarcar todos los objetos que gestiona el núcleo y, de hecho, los 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 administració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 . [11] La mayoría de las arquitecturas informáticas comerciales carecen de dicho soporte MMU para capacidades.
Un enfoque alternativo es simular capacidades utilizando dominios jerárquicos comúnmente admitidos. En este enfoque, cada objeto protegido debe residir en un espacio de direcciones al que la aplicación no tiene acceso; el kernel 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 kernel luego verifica si la capacidad de la aplicación le otorga permiso para realizar la acción solicitada y, si está permitido, realiza el acceso (ya sea directamente, o delegando la solicitud a otro proceso a nivel de usuario). El costo de rendimiento de la conmutación del espacio de direcciones limita la viabilidad 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 de los que no se espera que funcionen rápidamente. [12] [13]
Si el firmware no admite mecanismos de protección, es posible simular la protección en un nivel superior, por ejemplo simulando capacidades mediante la manipulación de tablas de páginas , pero existen implicaciones en el rendimiento. [14] Sin embargo, la falta de soporte de hardware puede no ser un problema para los sistemas que optan por utilizar protección basada en el idioma. [15]
Una decisión importante en el diseño del kernel es la elección de los niveles de abstracción donde se deben implementar las políticas y mecanismos de seguridad. Los mecanismos de seguridad del kernel desempeñan un papel fundamental a la hora de respaldar la seguridad en niveles superiores. [11] [16] [17] [18] [19]
Un enfoque es utilizar soporte de firmware y kernel para la tolerancia a fallas (ver arriba) y crear una política de seguridad para comportamientos maliciosos además de eso (agregando características como mecanismos de criptografía cuando sea necesario), delegando cierta responsabilidad al compilador . Los enfoques que delegan la aplicación de la política de seguridad al compilador y/o al nivel de la aplicación a menudo se denominan seguridad basada en el lenguaje .
La falta de muchos mecanismos de seguridad críticos en los principales sistemas operativos actuales impide la implementación de políticas de seguridad adecuadas en el nivel de abstracción de aplicaciones . [16] De hecho, un error común en la seguridad informática es que cualquier política de seguridad se puede implementar en una aplicación independientemente del soporte del kernel. [dieciséis]
Según los desarrolladores de Mars Research Group, la falta de aislamiento es uno de los principales factores que socavan la seguridad del kernel. [20] Proponen su marco de aislamiento de controladores para protección, principalmente en el kernel de Linux. [21] [22]
Los sistemas informáticos típicos de hoy utilizan reglas impuestas por hardware sobre qué programas pueden acceder a qué datos. El procesador monitorea la ejecución y detiene un programa que viola una regla, como un proceso de usuario que intenta escribir en la memoria del kernel. En sistemas que carecen de soporte para capacidades, los procesos se aíslan entre sí mediante el uso de espacios de direcciones separados. [23] Las llamadas desde procesos de usuario al kernel se regulan exigiéndoles que utilicen uno de los métodos de llamada al sistema descritos anteriormente.
Un enfoque alternativo es utilizar protección basada en el idioma. En un sistema de protección basado en lenguaje , el kernel sólo permitirá la ejecución de código que haya sido producido por un compilador de lenguaje confiable . Entonces, el lenguaje puede diseñarse de manera que al programador le resulte imposible ordenarle que haga algo que viole un requisito de seguridad. [15]
Las ventajas de este enfoque incluyen:
Las desventajas incluyen:
Ejemplos de sistemas con protección basada en lenguaje incluyen JX y Singularity de Microsoft .
Edsger Dijkstra demostró que desde un punto de vista lógico, las operaciones de bloqueo y desbloqueo atómico que operan en semáforos binarios son primitivas suficientes para expresar cualquier funcionalidad de cooperación de procesos. [24] Sin embargo, este enfoque generalmente se considera deficiente en términos de seguridad y eficiencia, mientras que un enfoque de transmisión de mensajes es más flexible. [25] También están disponibles otros enfoques (ya sea 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 de manera uniforme con otros procesos, como procesos cooperativos paralelos, fue propuesta e implementada por primera vez por Brinch Hansen (aunque se sugirieron ideas similares en 1967 [26] [27] ). En la descripción que hace Hansen de esto, los procesos "comunes" se denominan procesos internos , mientras que los dispositivos de E/S se denominan procesos externos . [25]
De manera 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 controlador o un bloqueo del sistema. Con esto, dependiendo de la complejidad del dispositivo, algunos dispositivos pueden volverse sorprendentemente complejos de programar y utilizar varios controladores diferentes. Por esto, es importante proporcionar una interfaz más abstracta para administrar el dispositivo. Esta interfaz normalmente la realiza un controlador de dispositivo o una capa de abstracción de hardware. Con frecuencia, las aplicaciones requerirán acceso a estos dispositivos. El kernel debe mantener la lista de estos dispositivos consultándolos al sistema de alguna manera. Esto se puede hacer a través del BIOS o mediante uno de los diversos buses del sistema (como PCI/PCIE o USB). Usando un ejemplo de controlador de video, cuando una aplicación solicita una operación en un dispositivo, como mostrar un carácter, el kernel debe enviar esta solicitud al controlador de video activo actual. El controlador de vídeo, a su vez, debe realizar esta solicitud. Este es un ejemplo de comunicación entre procesos (IPC).
Las tareas y características enumeradas anteriormente se pueden proporcionar de muchas maneras que difieren entre sí en diseño e implementación.
El principio de separación de mecanismo y política es la diferencia sustancial entre la filosofía de los núcleos micro y monolíticos. [28] [29] Aquí un mecanismo es el apoyo que permite la implementación de muchas políticas diferentes, mientras que una política es un "modo de operación" particular. Ejemplo:
Debido a que el mecanismo y la política están separados, la política se puede cambiar fácilmente para, por ejemplo, requerir el uso de un token de seguridad .
En el microkernel mínimo solo se incluyen algunas políticas muy básicas, [29] y sus mecanismos permiten que lo que se ejecuta encima del kernel (el resto del sistema operativo y las demás aplicaciones) decida qué políticas adoptar (como gestión de memoria, programación de procesos de alto nivel, gestión de sistemas de archivos, etc.). [5] [25] En cambio, un núcleo monolítico tiende a incluir muchas políticas, lo que restringe el resto del sistema a depender de ellas.
Per Brinch Hansen presentó argumentos a favor de la separación entre mecanismo y política. [5] [25] El hecho de no cumplir adecuadamente esta separación es una de las principales causas de la falta de innovación sustancial en los sistemas operativos existentes, [5] un problema común en la arquitectura informática. [30] [31] [32] El diseño monolítico es inducido por el enfoque arquitectónico de protección "modo kernel"/"modo usuario" (técnicamente llamado dominios de protección jerárquica ), que es común en los sistemas comerciales convencionales; [33] de hecho, cada módulo que necesita protección se incluye preferiblemente en el núcleo. [33] Este vínculo entre el diseño monolítico y el "modo privilegiado" puede reconducirse a la cuestión clave de la separación mecanismo-política; [5] de hecho, el enfoque arquitectónico del "modo privilegiado" combina el mecanismo de protección con las políticas de seguridad, mientras que el principal enfoque arquitectónico alternativo, el direccionamiento basado en capacidades , distingue claramente entre los dos, lo que conduce naturalmente a un diseño de microkernel [5] ( ver Separación de protección y seguridad ).
Mientras que los núcleos monolíticos ejecutan todo su código en el mismo espacio de direcciones ( espacio del núcleo ), los microkernels intentan ejecutar la mayoría de sus servicios en el espacio del usuario, con el objetivo de mejorar la capacidad de mantenimiento y la modularidad del código base. [4] La mayoría de los núcleos no encajan exactamente en una de estas categorías, sino que se encuentran entre estos dos diseños. Estos se denominan núcleos híbridos . Se encuentran disponibles diseños más exóticos, como nanokernels y exokernels , pero rara vez se utilizan para sistemas de producción. El hipervisor Xen , por ejemplo, es un exokernel.
En un núcleo monolítico, todos los servicios del sistema operativo se ejecutan junto con el hilo principal del núcleo, por lo que también residen en la misma área de memoria. Este enfoque proporciona un acceso rico y potente al hardware. El desarrollador de UNIX, Ken Thompson, afirmó que "en [su] opinión, es más fácil implementar un núcleo monolítico". [34] Las principales desventajas de los núcleos monolíticos son las dependencias entre los componentes del sistema (un error en un controlador de dispositivo podría bloquear todo el sistema) y el hecho de que los núcleos grandes pueden resultar muy difíciles de mantener; Thompson también afirmó que "también es más fácil que [un núcleo monolítico] se convierta en un desastre rápidamente a medida que se modifica". [34]
Los núcleos monolíticos, que tradicionalmente han sido utilizados por sistemas operativos tipo Unix, contienen todas las funciones principales del sistema operativo y los controladores de dispositivos. Un kernel monolítico es un único programa que contiene todo el código necesario para realizar todas las tareas relacionadas con el kernel. Cada parte a la que acceden la mayoría de los programas que no se pueden colocar en una biblioteca se encuentra en el espacio del kernel: controladores de dispositivos, programador, manejo de memoria, sistemas de archivos y pilas de red. Se proporcionan muchas llamadas al sistema a las aplicaciones para permitirles acceder a todos esos servicios. Un núcleo monolítico, aunque inicialmente está cargado con subsistemas que pueden no ser necesarios, puede ajustarse hasta un punto en el que sea tan rápido o más rápido que el que fue diseñado específicamente para el hardware, aunque más relevante en un sentido general.
Los kernels monolíticos modernos, como el kernel de Linux , el kernel de FreeBSD , el kernel de AIX , el kernel de HP-UX y el kernel de Solaris , todos los cuales entran en la categoría de sistemas operativos similares a Unix, admiten módulos de kernel cargables , lo que permite módulos para cargarse en el kernel en tiempo de ejecución, lo que permite una fácil extensión de las capacidades del kernel según sea necesario, al tiempo que ayuda a minimizar la cantidad de código que se ejecuta en el espacio del kernel.
La mayor parte del trabajo en el núcleo monolítico se realiza mediante llamadas al sistema. Estas son interfaces, generalmente mantenidas en una estructura tabular, que acceden a algún subsistema dentro del kernel, como las operaciones de disco. Básicamente, las llamadas se realizan dentro de los programas y se pasa una copia verificada de la solicitud a través de la llamada al sistema. Por lo tanto, no está muy lejos para viajar. El kernel monolítico de Linux puede hacerse extremadamente pequeño no sólo por su capacidad para cargar módulos dinámicamente sino también por su facilidad de personalización. De hecho, hay algunas versiones que son lo suficientemente pequeñas como para caber junto con una gran cantidad de utilidades y otros programas en un solo disquete y aun así proporcionar un sistema operativo completamente funcional (uno de los 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 integrados .
Estos tipos de núcleos constan de las funciones principales del sistema operativo y los controladores de dispositivo con la capacidad de cargar módulos en tiempo de ejecución. Proporcionan abstracciones ricas y poderosas del hardware subyacente. Proporcionan 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 gestión de procesos, concurrencia y gestión de memoria en varios módulos que se ejecutan en modo supervisor. Este diseño tiene varios defectos y limitaciones:
Microkernel (también abreviado μK o uK) es el término que describe un enfoque para el diseño de sistemas operativos mediante el cual la funcionalidad del sistema se traslada del "núcleo" tradicional a un conjunto de "servidores" que se comunican a través de un núcleo "mínimo". , dejando lo menos posible en el "espacio del sistema" y la mayor cantidad posible en el "espacio del usuario". Un microkernel diseñado para una plataforma o dispositivo específico solo tendrá lo que necesita para funcionar. 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 administración de memoria , multitarea y comunicación entre procesos . Otros servicios, incluidos los que normalmente proporciona el núcleo, como las redes , se implementan en programas del espacio de usuario, denominados servidores . Los micronúcleos son más fáciles de mantener que los monolíticos, pero la gran cantidad de llamadas al sistema y cambios de contexto pueden ralentizar el sistema porque normalmente generan más gastos generales que las llamadas a funciones simples.
Sólo las partes que realmente requieren estar en un modo privilegiado están en el espacio del kernel: IPC (Comunicación entre procesos), programador básico o primitivas de programación, manejo básico de memoria, primitivas de E/S básicas. Muchas partes críticas ahora se ejecutan en el espacio del usuario: el programador completo, el manejo de la memoria, los sistemas de archivos y las pilas de red. Los micronúcleos se inventaron como reacción al diseño tradicional de núcleo "monolítico", mediante el cual toda la funcionalidad del sistema se colocaba en un programa estático que se ejecutaba en un modo de "sistema" especial del procesador. En el microkernel, sólo se realizan las tareas más fundamentales, 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 micro kernels son QNX y HURD. En el caso de QNX y Hurd, las sesiones de usuario pueden ser instantáneas completas del propio sistema o vistas como se le conoce. La esencia misma de la arquitectura microkernel ilustra algunas de sus ventajas:
La mayoría de los microkernels utilizan un sistema de paso de mensajes para manejar solicitudes de un servidor a otro. El sistema de paso de mensajes generalmente opera por puerto con el microkernel. Por ejemplo, si se envía una solicitud de más memoria, se abre un puerto con el microkernel y se envía la solicitud. Una vez dentro del microkernel, los pasos son similares a las llamadas al sistema. La razón fundamental fue que aportaría modularidad a la arquitectura del sistema, lo que implicaría un sistema más limpio, más fácil de depurar o modificar dinámicamente, personalizable según las necesidades de los usuarios y con mayor rendimiento. Forman parte de sistemas operativos como GNU Hurd , MINIX , MkLinux , QNX y Redox OS . Aunque los micronúcleos son muy pequeños por sí mismos, en combinación con todo el código auxiliar necesario, suelen ser más grandes que los núcleos monolíticos. Los defensores de los núcleos monolíticos también señalan que la estructura de dos niveles de los sistemas de micronúcleo, en los que la mayor parte del sistema operativo no interactúa directamente con el hardware, genera un costo no insignificante en términos de eficiencia del sistema. Estos tipos de núcleos normalmente proporcionan sólo 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. Las otras funciones, como ejecutar los procesos de hardware, no son manejadas directamente por microkernels. Los defensores de los micronúcleos señalan que los núcleos monolíticos tienen la desventaja de que un error en el núcleo puede provocar que todo el sistema falle. Sin embargo, con un microkernel, si un proceso del kernel falla, aún es posible evitar una falla del sistema en su conjunto simplemente reiniciando el servicio que causó el error.
Otros servicios proporcionados por el kernel, como las redes, se implementan en programas del espacio de usuario denominados servidores . Los servidores permiten modificar el sistema operativo simplemente iniciando y deteniendo programas. Para una máquina sin soporte de red, por ejemplo, el servidor de red no se inicia. La tarea de entrar y salir del núcleo para mover datos entre las distintas aplicaciones y servidores genera una sobrecarga que va en detrimento de la eficiencia de los micronúcleos en comparación con los núcleos monolíticos.
Sin embargo, existen desventajas en el micronúcleo. Algunos son:
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) porque si no es necesario ejecutar muchos procesos, las complicaciones de la gestión de procesos se mitigan de manera efectiva.
Un microkernel permite la implementación de la parte restante del sistema operativo como un programa de aplicación normal escrito en un lenguaje de alto nivel , y el uso de diferentes sistemas operativos sobre el mismo kernel sin cambios. También es posible cambiar dinámicamente entre sistemas operativos y tener más de uno activo simultáneamente. [25]
A medida que crece el núcleo de la computadora, también crece el tamaño y la vulnerabilidad de su base informática confiable ; y, además de reducir la seguridad, existe el problema de aumentar la huella de memoria . Esto se mitiga hasta cierto punto perfeccionando el sistema de memoria virtual , pero no todas las arquitecturas informáticas tienen soporte para memoria virtual. [b] Para reducir la huella del kernel, se debe realizar una edición exhaustiva para eliminar cuidadosamente el código innecesario, lo que puede ser muy difícil con interdependencias no obvias entre partes de un kernel 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 que los núcleos monolíticos eran obsoletos. [ cita necesaria ] 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 . [35] Hay mérito en ambos lados del argumento presentado en el debate Tanenbaum-Torvalds .
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. [36] Algunos desarrolladores también sostienen que los sistemas monolíticos son extremadamente eficientes si están bien escritos. [36] El modelo monolítico tiende a ser más eficiente [37] mediante el uso de memoria de kernel compartida, en lugar del sistema IPC más lento de diseños de microkernel, que generalmente se basa en el paso de mensajes . [ cita necesaria ]
El rendimiento de los micronúcleos fue pobre tanto en los años 1980 como a principios de los 1990. [38] [39] Sin embargo, los estudios que midieron empíricamente el rendimiento de estos micronúcleos no analizaron las razones de tal ineficiencia. [38] Las explicaciones de estos datos se dejaron al "folclore", con el supuesto 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 al aumento de la frecuencia de los cambios de contexto . [38]
De hecho, como se supuso en 1995, las razones del bajo rendimiento de los microkernels también podrían haber sido: (1) una ineficiencia real de todo el enfoque de los microkernels , (2) los conceptos particulares implementados en esos microkernels, y (3) la implementación particular de esos conceptos. Por tanto, quedaba por estudiar si la solución para construir un microkernel eficiente era, a diferencia de intentos anteriores, aplicar las técnicas de construcción correctas. [38]
Por otro lado, la arquitectura de dominios de protección jerárquica que conduce al diseño de un núcleo monolítico [33] tiene un importante inconveniente de rendimiento 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" y "modo supervisor"), ya que esto requiere copiar el mensaje por valor . [40]
Los núcleos híbridos se utilizan en la mayoría de los sistemas operativos comerciales, como Microsoft Windows NT 3.1, NT 3.5, NT 3.51, NT 4.0, 2000, XP, Vista, 7, 8, 8.1 y 10. El propio macOS de Apple utiliza un núcleo híbrido llamado XNU. que se basa en el código del kernel Mach de OSF/1 (OSFMK 7.3) [41] y el kernel monolítico de FreeBSD . Son similares a los microkernels, excepto que incluyen código adicional en el espacio del kernel para aumentar el rendimiento. Estos núcleos representan un compromiso que fue implementado por algunos desarrolladores para dar cabida a las principales ventajas de los núcleos monolíticos y micro. Estos tipos de núcleos son extensiones de micro núcleos con algunas propiedades de los núcleos monolíticos. A diferencia de los núcleos monolíticos, estos tipos de núcleos no pueden cargar módulos en tiempo de ejecución por sí solos. 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 del usuario.
Muchos núcleos tradicionalmente monolíticos ahora al menos están agregando (o utilizando) la capacidad del módulo. El más conocido de estos núcleos es el núcleo de Linux. Básicamente, el kernel modular puede tener partes integradas en el binario central del kernel o binarios que se cargan en la memoria según demanda. Es importante tener en cuenta que un módulo con código contaminado tiene el potencial de desestabilizar un kernel en ejecución. Mucha gente se confunde sobre este punto cuando se habla de micronúcleos. Es posible escribir un controlador para un microkernel en un espacio de memoria completamente separado y probarlo antes de "entrar" en funcionamiento. Cuando se carga un módulo del kernel, accede al espacio de memoria de la porción monolítica agregándole lo que necesita, abriendo así la puerta a una posible contaminación. Algunas ventajas del kernel modular (o) híbrido son:
Los módulos, generalmente, se comunican con el kernel mediante una interfaz de módulo de algún tipo. La interfaz es generalizada (aunque particular de un sistema operativo determinado) por lo que no siempre es posible utilizar módulos. A menudo, los controladores de dispositivos pueden necesitar más flexibilidad que la que ofrece la interfaz del módulo. Básicamente, se trata de dos llamadas al sistema y, a menudo, las comprobaciones de seguridad que sólo deben realizarse una vez en el núcleo monolítico ahora se pueden realizar dos veces. Algunas de las desventajas del enfoque modular son:
Un nanokernel delega prácticamente todos los servicios (incluidos incluso los más básicos, como los controladores de interrupciones o el temporizador ) a los controladores de dispositivos para hacer que el requisito de memoria del kernel sea incluso menor que el de un microkernel tradicional. [42]
Los exokernels son un enfoque aún experimental para el diseño de sistemas operativos. Se diferencian de otros tipos de núcleos en que limitan su funcionalidad a la protección y multiplexación del hardware en bruto, sin proporcionar abstracciones de hardware sobre las cuales desarrollar aplicaciones. Esta separación entre la protección del hardware y la gestión del hardware permite a los desarrolladores de aplicaciones determinar cómo hacer el uso más eficiente del hardware disponible para cada programa específico.
Los exokernels en sí mismos son extremadamente pequeños. Sin embargo, van acompañados de sistemas operativos de biblioteca (ver también unikernel ), que brindan a los desarrolladores de aplicaciones las funcionalidades de un sistema operativo convencional. Esto se reduce a que cada usuario escriba su propio resto del kernel desde casi cero, lo cual es una tarea muy arriesgada, compleja y bastante desalentadora, particularmente en un entorno orientado a la producción con tiempo limitado, razón por la cual los exokernels nunca han cogido en. [ cita necesaria ] Una ventaja importante de los sistemas basados en exokernel es que pueden incorporar múltiples sistemas operativos de biblioteca, cada uno exportando una API diferente , por ejemplo, una para el desarrollo de UI de alto nivel y otra para 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 comunicaciones entre procesos como paso de mensajes . [43] [44] Barrelfish fue el primer sistema operativo descrito como multikernel.
Estrictamente hablando, no se requiere un sistema operativo (y por tanto, un kernel) para ejecutar una computadora. Los programas se pueden cargar y ejecutar directamente en la máquina "bare metal", siempre que los autores de esos programas estén dispuestos a trabajar sin ninguna abstracción de hardware o soporte de sistema operativo. La mayoría de las primeras computadoras funcionaron de esta manera durante la década de 1950 y principios de la de 1960, que se reiniciaban y recargaban entre la ejecución de diferentes programas. Con el tiempo, pequeños programas auxiliares, como cargadores de programas y depuradores , quedaron en la memoria entre ejecuciones o se cargaron desde la ROM . A medida que se desarrollaron, formaron la base de lo que se convirtieron en los primeros núcleos del sistema operativo. El enfoque "bare metal" todavía se utiliza hoy en día en algunas consolas de videojuegos y sistemas integrados , [45] pero en general, las computadoras más nuevas utilizan sistemas operativos y kernels modernos.
En 1969, el sistema de multiprogramación RC 4000 introdujo la filosofía de diseño del sistema de un pequeño núcleo "sobre el cual se podrían construir de manera ordenada sistemas operativos para diferentes propósitos", [46] lo que se llamaría el enfoque del micronúcleo.
En la década anterior a Unix , la potencia de las computadoras había aumentado enormemente, hasta el punto de que los operadores de computadoras buscaban nuevas formas de hacer que la gente usara su tiempo libre en sus máquinas. Uno de los principales avances durante esta era fue el tiempo compartido , mediante el cual varios usuarios obtenían pequeñas porciones de tiempo de computadora, a un ritmo en el que parecía que cada uno estaba conectado a su propia máquina, más lenta. [47]
El desarrollo de sistemas de tiempo compartido generó una serie de problemas. Una era que los usuarios, particularmente en las universidades donde se estaban desarrollando los sistemas, parecían querer hackear el sistema para obtener más tiempo de CPU . Por esta razón, la seguridad y el control de acceso se convirtieron en un foco importante del proyecto Multics en 1965. [48] Otro problema constante era el manejo adecuado de los recursos informáticos: los usuarios pasaban la mayor parte del tiempo mirando el terminal y pensando qué ingresar en lugar de hacerlo realmente. utilizando los recursos de la computadora, y un sistema de tiempo compartido debería darle tiempo de CPU a un usuario activo durante estos períodos. Finalmente, los sistemas típicamente ofrecían una jerarquía de memoria de varias capas de profundidad, y la partición de este costoso recurso condujo a importantes desarrollos en los sistemas de memoria virtual .
El Commodore Amiga se lanzó en 1985 y estuvo entre los primeros (y ciertamente los más exitosos) ordenadores domésticos en presentar una arquitectura de núcleo avanzada. El componente ejecutivo del kernel de AmigaOS, exec.library , utiliza un diseño de paso de mensajes de microkernel, pero hay otros componentes del kernel, como gráficos.library , que tienen acceso directo al hardware. No hay protección de memoria y el kernel casi siempre se ejecuta en modo de usuario. Sólo se ejecutan acciones especiales en modo kernel, y las aplicaciones en modo usuario pueden pedirle al sistema operativo que ejecute su código en modo kernel.
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 del cálculo era la transformación de datos . [49]
Por ejemplo, las impresoras se representaban como un "archivo" en una ubicación conocida: cuando los datos se copiaban en el archivo, se imprimían. Otros sistemas, para proporcionar una funcionalidad similar, tendían a virtualizar dispositivos en un nivel inferior; es decir, tanto los dispositivos como los archivos serían instancias de algún concepto de nivel inferior . La virtualización del sistema a nivel de archivos permitió a los usuarios manipular todo el sistema utilizando sus utilidades y conceptos de administración de archivos existentes, simplificando drásticamente la operación. Como extensión del mismo paradigma, Unix permite a los programadores manipular archivos utilizando una serie de pequeños programas, utilizando el concepto de pipes , que permitía a los usuarios completar operaciones por etapas, alimentando un archivo a través de una cadena de herramientas de un solo propósito. Aunque el resultado final fue el mismo, el uso de programas más pequeños de esta manera aumentó drásticamente la flexibilidad y la facilidad de desarrollo y uso, permitiendo al usuario modificar su flujo de trabajo agregando 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 utilitarios que impulsan la mayoría de las operaciones; segundo, el kernel que ejecuta los programas. [49] 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, [c] que actúa como 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 kernel no intervino en absoluto en el espacio del 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 un flujo de bytes ya no era tan universalmente aplicable como lo era antes. Aunque un terminal podría tratarse como un archivo o un flujo de bytes, en el que se imprime o se lee, no parece que ocurra lo mismo con una interfaz gráfica de usuario . La creación de redes planteó otro problema. Incluso si la comunicación de red puede compararse con el acceso a archivos, la arquitectura orientada a paquetes de bajo nivel trataba con fragmentos discretos de datos y no con archivos completos. A medida que crecía la capacidad de las computadoras, Unix se volvió cada vez más saturado de código. También se debe a que la modularidad del kernel de Unix es ampliamente escalable. [50] Mientras que los núcleos podrían haber tenido 100.000 líneas de código en los años setenta y ochenta, núcleos como Linux , de los sucesores modernos de Unix como GNU , tienen más de 13 millones de líneas. [51]
Los derivados modernos de Unix se basan generalmente en núcleos monolíticos de carga de módulos. Ejemplos de esto son el kernel de Linux en muchas distribuciones de GNU , IBM AIX , así como las variantes de kernel de Berkeley Software Distribution como FreeBSD , DragonFly BSD , OpenBSD , NetBSD y macOS . Aparte de estas alternativas, los desarrolladores aficionados mantienen una comunidad activa de desarrollo de sistemas operativos , poblada por núcleos 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. [52]
Apple lanzó por primera vez su Mac OS clásico en 1984, incluido con su computadora personal Macintosh . Apple pasó a un diseño de nanokernel en Mac OS 8.6. Frente a esto, el macOS moderno (originalmente llamado Mac OS X) se basa en Darwin , que utiliza un kernel híbrido llamado XNU , que fue creado combinando el kernel 4.3BSD y el kernel Mach . [53]
Microsoft Windows se lanzó por primera vez en 1985 como complemento de MS-DOS . Debido a su dependencia de otro sistema operativo, las versiones iniciales de Windows, anteriores a Windows 95, se consideraban un entorno operativo (no confundir con un sistema operativo ). Esta línea de productos continuó evolucionando durante las décadas de 1980 y 1990, con la serie Windows 9x agregando direccionamiento de 32 bits y multitarea preventiva; pero terminó con el lanzamiento de Windows Me en 2000.
Microsoft también desarrolló Windows NT , un sistema operativo con una interfaz muy similar, pero destinado a usuarios empresariales y de alto nivel. Esta línea comenzó con el lanzamiento de Windows NT 3.1 en 1993 y se presentó a los usuarios generales 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 núcleo mismo contiene tareas como el Administrador de ventanas y los Administradores de IPC, con un modelo de subsistema en capas cliente/servidor. [54] Fue diseñado como un microkernel modificado , ya que el kernel de Windows NT fue influenciado por el microkernel Mach pero no cumple con todos los criterios de un microkernel puro.
Programa de supervisión o supervisor es un programa de computadora , generalmente parte de un sistema operativo , que controla la ejecución de otras rutinas y regula la programación del trabajo , operaciones de entrada/salida , 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 asoció esencialmente con la línea de sistemas operativos mainframe de IBM que comenzaba con OS/360 . En otros sistemas operativos, el supervisor generalmente se denomina núcleo.
En la década de 1970, IBM abstrajo aún más el estado de supervisor del hardware, lo que dio como resultado un hipervisor que permitía la virtualización total , es decir, la capacidad de ejecutar múltiples sistemas operativos en la misma máquina de forma totalmente independiente unos de otros. De ahí que el primer sistema de este tipo se llamara Máquina Virtual o VM .
Aunque Mach , desarrollado por Richard Rashid en la Universidad Carnegie Mellon , es el micronúcleo de propósito general más conocido, se han desarrollado otros micronúcleos con objetivos más específicos. La familia de micronúcleos L4 (principalmente los núcleos L3 y L4) se creó para demostrar que los micronúcleos no son necesariamente lentos. [55] Las implementaciones más nuevas, como Fiasco y Pistachio, pueden ejecutar Linux junto con otros procesos L4 en espacios de direcciones separados. [56] [57]
Además, QNX es un microkernel que se utiliza principalmente en sistemas integrados , [58] y el software de código abierto MINIX , aunque se creó originalmente con fines educativos, ahora se centra en ser un sistema operativo de microkernel altamente confiable y autorreparable .
. . . Casi todas las llamadas al sistema [son] invocadas desde programas C llamando a un procedimiento de biblioteca. . . El procedimiento bibliotecario. . . ejecuta una instrucción TRAP para cambiar del modo de usuario al modo kernel e iniciar la ejecución. . .
Los últimos 25 años han demostrado que la investigación sobre la arquitectura de los sistemas operativos tuvo un efecto menor en los sistemas principales [ sic ] existentes.
La naturaleza estrechamente acoplada de un kernel monolítico le permite hacer un uso muy eficiente del hardware subyacente [...] Los microkernels, por otro lado, ejecutan muchos más procesos centrales en el área de usuario. [...] Desafortunadamente, estos beneficios tienen el costo de que el microkernel tenga que pasar mucha información dentro y fuera del espacio del kernel a través de un proceso conocido como cambio de contexto. Los cambios de contexto introducen una sobrecarga considerable y, por lo tanto, dan como resultado una penalización en el rendimiento.
