Un microkernel es un núcleo mínimo del sistema operativo de la computadora que, en su forma más pura, no proporciona ningún servicio operating-system en absoluto, sólo los mecanismos del necesitaron ejecutar tales servicios, tales como gerencia baja del espacio de dirección, gerencia del hilo de rosca, y la comunicación entre procesos (IPC). El microkernel es la única parte del sistema que ejecuta en un modo del núcleo. Los servicios operating-system reales son proporcionados por los servidores Usuario-modo . Éstos incluyen los sistemas de ficheros de los apilados del protocolo de los drivers de dispositivo y código del interfaz de usuario .

Esto da lugar a una estructura de sistema que sea drástico diferente de los núcleos monolíticos establecidos que estes 3ultimo tienen tradicionalmente una estructura vertical-acodada, donde los usos obtienen servicios realizando una llamada de sistema específica para cada servicio. En cambio, características de un sistema microkernel-basadas una estructura horizontal, donde los servicios de sistema son obtenidos ejecutando una llamada de sistema del IPC tratada a un servidor particular.

Microkernels es estrechamente vinculado al Exokernels que también hacen que mucho en común con el Hypervisors pero estes 3ultimo no haga ninguna demanda al minimality, y se especializa a las máquinas virtuales favorables el microkernel L4 se utiliza con frecuencia como hypervisor, que indica que un microkernel es una puesta en práctica posible de un hypervisor. El Nanokernel del término se utiliza históricamente para distinguir de microkernels anteriores que contuvieron servicios de sistema reales, pero el principio del minimality del usado por el Jochen Liedtke en el diseño del microkernel L4 implica que estos términos tienen el mismo significado; el microkernel es la terminología moderna.

Introducción

Los núcleos tempranos del sistema operativo eran algo pequeños, en parte porque la memoria de computadora era limitada. Mientras que la capacidad de computadoras creció, el número de dispositivos que el núcleo tuvo que controlar también creció. Las versiones tempranas UNIX tenían núcleos del tamaño absolutamente modesto, aunque esos núcleos contuvieron a encargados de los drivers de dispositivo y del sistema de ficheros. Cuando los espacios de dirección aumentaron a partir del 16 a 32 pedacitos, el diseño del núcleo fue obstaculizado no más por la arquitectura de hardware, y los núcleos comenzaron a crecer. (Véase la historia de Unix ).

Berkeley UNIX (DEB ) comenzó la era de núcleos grandes. Además de gestionar un sistema básico que consistía en la CPU, los discos y las impresoras, DEB comenzaron a agregar los sistemas de ficheros adicionales un sistema completo del establecimiento de una red del TCP/IP, y un número de " virtual" dispositivos que permitieron que los programas existentes trabajaran invisiblemente sobre la red. Este crecimiento continuó por varias décadas, dando por resultado núcleos con millones de líneas del código fuente . Como resultado de este crecimiento, los núcleos eran insectos más propensos y llegaron a ser cada vez más difíciles de mantener.

El microkernel fue diseñado para tratar el crecimiento cada vez mayor de los núcleos y de las dificultades que vinieron con ellas. En teoría, el diseño del microkernel permite una gerencia más fácil del código debido a su división en servicios del Usuario-espacio . Esto también permite seguridad y estabilidad crecientes resultando de la cantidad reducida de código que funciona en el modo del núcleo.

Por ejemplo, si un servicio del establecimiento de una red estrellara debido al desbordamiento del almacenador intermediario, sólo la memoria del servicio del establecimiento de una red sería corrompida, todavía saliendo del resto del sistema funcional. En un núcleo monolítico tradicional, el desbordamiento podría corromper posiblemente la memoria de otros conductores y posiblemente del núcleo sí mismo, que podrían bloquear el sistema entero.

Comunicación entre procesos

La comunicación entre procesos (IPC) es cualquier mecanismo que permita que los procesos separados comuniquen con uno a, generalmente enviando los mensajes . (la memoria compartida es en realidad también un mecanismo de la comunicación entre procesos, pero las siglas IPC refieren generalmente solamente al mensaje que pasa, y es este 3ultimo que es particularmente relevante a los microkernels.) Esto permite que el sistema operativo sea construido de un número de pequeños programas llamados los servidores, que son utilizados por otros programas sobre el sistema, invocados vía el IPC. La mayoría o toda la ayuda para el hardware periférico se maneja de este modo, con los servidores para los drivers de dispositivo, los apilados del protocolo de red, los sistemas de ficheros, los gráficos, el etc.

El IPC puede ser síncrono o asincrónico. El IPC asincrónico es análogo a la comunicación de la red: el remitente envía un mensaje y continúa ejecutando. El receptor comprueba (las encuestas) para saber si hay la disponibilidad del mensaje intentando una recepción, o se alerta a él vía un cierto mecanismo de la notificación. El IPC asincrónico requiere que el núcleo mantenga almacenadores intermediarios y las coletas para los mensajes, y los repartos con el almacenador intermediario desbordan; también requiere el copiado doble de los mensajes (remitente al núcleo y al núcleo al receptor). En el IPC síncrono, los primeros bloques del partido (remitente o receptor) hasta el otro partido están listos para realizar el IPC. No requiere el buffering o copias múltiples, pero el rendez-vouz implícito puede hacer la programación difícil. La mayoría de los programadores prefieren asincrónico envían y síncrono recibir.

Síncrono típicamente apoyada de primera generación de los microkernels así como el IPC asincrónico, y sufrido de funcionamiento pobre del IPC. El Jochen Liedtke identificó diseño y la puesta en práctica de los mecanismos del IPC como la razón subyacente de esta degradación de las prestaciones. En su microkernel L4 él inició las técnicas que llevan a una reducción de la orden-de-magnitud de los costes del IPC. Éstos incluyen una llamada de sistema del IPC que apoye un envío tan bien como una operación de la recepción, haciendo todo el IPC que es síncrono, y pasando tantos datos como sea posible en registros. Además, Liedtke introdujo el concepto del interruptor del proceso directo del, donde durante una ejecución del IPC que un contexto (incompleto) cambia se realiza del remitente directo al receptor. Si, como en L4, la parte o todo el mensaje se pasa en registros, ésta transfiere en-coloca la parte del mensaje sin el copiado en absoluto. Además, los gastos indirectos de invocar el planificador se evitan; esto es especialmente beneficioso en el caso común donde el IPC se utiliza en un RPC - mecanografiar la manera por un cliente que invoca un servidor. Otra optimización, llamada el de previsión perezoso, evita atravesar coletas de previsión durante el IPC dejando los hilos de rosca que bloquean durante el IPC en la fila de procesos preparados. Una vez que se invoca el planificador, mueve tales hilos de rosca a la fila de procesos en espera apropiada. Mientras que en muchos casos un hilo de rosca consigue desbloqueado antes de la invocación siguiente del planificador, este acercamiento ahorra el trabajo significativo. Los acercamientos similares han sido adoptados desde entonces por QNX y el Minix 3 .

En un sistema del servidor de cliente, la mayoría de la comunicación es esencialmente síncrona, incluso si usa primitivos asincrónicos, como la operación típica está un cliente que invoca un servidor y después que espera una contestación. Pues también se presta a una puesta en práctica más eficiente, los microkernels modernos siguen generalmente el plomo de L4 y proporcionan solamente un primitivo síncrono del IPC. El IPC asincrónico se puede ejecutar en tapa usando los hilos de rosca del ayudante. Sin embargo, las versiones de L4 desplegado en productos comerciales han encontrado necesario agregar un mecanismo asincrónico de la notificación para mejorar la comunicación asincrónica de la ayuda. Esta señal - como mecanismo no lleva datos y por lo tanto no requiere el buffering por el núcleo.

Pues el IPC síncrono bloquea el primer partido hasta que el otro esté listo, el uso sin restricción podría llevar fácilmente a los callejones sin salida. Además, un cliente podría montar fácilmente un ataque del Negación-de-servicio contra un servidor enviando una petición y nunca intentando recibir la contestación. Por lo tanto el IPC síncrono debe proporcionar medios de prevenir el bloqueo indefinido. Muchos microkernels proporcionan los descansos en las llamadas del IPC, que limitan el tiempo de bloqueo. En la práctica, chosing valores del time out sensibles es difícil, y los sistemas utilizan casi inevitable los descansos infinitos para los clientes y los descansos cero para los servidores. Por consiguiente, la tendencia está hacia el abastecimiento de descansos arbitrarios, sino solamente una bandera que indique que el IPC debe fallar inmediatamente si el socio no está listo. Este acercamiento proporciona con eficacia una opción de los dos valores del time out de cero y del infinito. Las versiones recientes de L4 y de MInix han ido abajo de esta trayectoria (más viejas versiones de descansos usados L4, al igual que QNX).

Servidores

Los servidores de Microkernel son programas como cualquier otros, salvo que las concesiones del núcleo alguno de él los privilegios de obrar recíprocamente con las partes de la memoria física que son de otra manera fuera de los límites a la mayoría de los programas. Esto permite que algunos servidores, particularmente drivers de dispositivo, obren recíprocamente directo con hardware.

Un sistema básico de los servidores para un microkernel de fines generales incluye los servidores del sistema de ficheros, los servidores del driver de dispositivo, los servidores del establecimiento de una red, los servidores de la exhibición, y los servidores del dispositivo del interfaz utilizador. Este sistema de servidores (extraídos QNX ) proporciona áspero el sistema de servicios ofrecidos por un núcleo monolítico de UNIX. Los servidores necesarios se encienden en el arranque de sistema y proporcionan servicios, tales como archivo, red, y acceso del dispositivo, a los programas de aplicación ordinarios. Con tales servidores funcionando en el ambiente de un uso del usuario, el desarrollo del servidor es similar al desarrollo de aplicaciones ordinario, algo que el proceso del construir-y-cargador necesario para el desarrollo del núcleo.

Además, mucho " crashes" se pueden corregir para por simplemente el la detención y el recomienzo del servidor . (En un sistema tradicional, un desplome en código un de los del núcleo-residente daría lugar a estrellarse entero de la máquina, forzando una reinicialización.) Sin embargo, la parte del estado de sistema se pierde con el servidor fall, por lo tanto este acercamiento requiere usos hacer frente a falta. Un buen ejemplo es un servidor responsable de conexiones del TCP/IP : Si se recomienza este servidor, los usos experimentarán un " lost" conexión, una ocurrencia normal en sistema conectado. Para otros servicios, la falta se espera y puede menos requerir cambios al código de uso. Para QNX, la capacidad de recomenzar se ofrece como el juego de herramientas de gran disponibilidad de QNX.

Para hacer todos los servidores reiniciables, algunos microkernels han concentrado en el adición de la varia base de datos - como técnicas como la réplica de las transacciones y la verificación para preservar el estado esencial a través del solo servidor recomienza. Un ejemplo es el ChorusOS, que fue apuntado en los usos de gran disponibilidad en el mundo de las telecomunicaciones . Características incluidas del estribillo para permitir cualquie " correctamente written" servidor que se recomenzará en cualquier momento, con los clientes usando esos servidores que son detenidos brevemente mientras que el servidor se trajo nuevamente dentro de su estado original. Sin embargo, tales características del núcleo son incompatibles con el principio del minimality, y por lo tanto no se proporcionan en los microkernels modernos, que en lugar de otro confían en protocolos user-level apropiados.

Drivers de dispositivo

Los drivers de dispositivo que realizan con frecuencia el acceso directo de memoria (acceso directo de memoria), y por lo tanto que pueden escribir a las localizaciones arbitrarias de la memoria física, incluyendo sobre las estructuras de datos del núcleo. Tales conductores deben por lo tanto ser confiados en. Es una idea falsa común esa esto significa que deben ser parte del núcleo. De hecho, un conductor no es intrínsecamente más o menos digno de confianza siendo parte del núcleo.

Mientras que funcionar con un driver de dispositivo en modo del usuario no reduce necesario el daño un conductor que comportarse mal puede causar, él es en la práctica beneficioso para la estabilidad de sistema en presencia (algo que malévolo) de conductores con errores: las violaciones por el código del conductor sí mismo del memoria-acceso (en comparación con el dispositivo) se pueden todavía coger por el hardware de la memoria-gerencia. Además, muchos dispositivos no son DMA-capable, sus conductores pueden ser hechos untrusted funcionándolas en modo del usuario. Recientemente, un número cada vez mayor de computadoras ofrece el IOMMUs muchos cuyo puede ser utilizado para restringir el acceso de un dispositivo a la memoria física. (Las unidades centrales de IBM han tenido IO MMUs desde el modelo 67 de IBM System/360 y el Sistema/370 .) Esto también permite que los conductores del usuario-modo hagan untrusted.

del Usuario-modo de los conductores microkernels del predate realmente. El sistema terminal (MTS) de Michigan, en 1967, apoyó los conductores del usuario-espacio, el primer sistema operativo que se diseñará con esa capacidad. Históricamente, los conductores eran menos de un problema, pues el número de dispositivos era pequeño y confiado en de todos modos, así que tenerlos en el núcleo simplificaron el diseño y evitaron problemas de funcionamiento potenciales. Esto llevó al estilo tradicional de UNIX, linux del conductor-en--núcleo, y de Windows. Con la proliferación de varias clases de periférico, la cantidad de código del conductor se extendió y en sistemas operativos modernos domina el núcleo en términos de tamaño de código.

Componentes esenciales

Mientras que un microkernel debe permitir el construir de servicios operating-system arbitrarios en tapa, debe proporcionar una cierta funcionalidad de la base. Por lo menos esto incluye:
algunos mecanismos para ocuparse de los espacios de dirección - esto se requiere para la protección de memoria de manejo;
una cierta abstracción de la ejecución para manejar la asignación de CPU - el rosca típicamente o las activaciones del planificador y
Comunicación entre procesos - requerida para invocar los servidores que funcionan en sus propios espacios de dirección. Este diseño mínimo fue iniciado por núcleo de s de Hansen Brinch el 'y el hypervisor VM de IBM. Se ha formalizado desde entonces en el principio del minimality del de Liedtke: el concepto del

A se tolera dentro del microkernel solamente si la mudanza de él fuera del núcleo, es decir, puestas en práctica competentes de permiso, prevendría la puesta en práctica del functionality.

requerido del sistema Todo se puede hacer en un programa de usuario, aunque los drivers de dispositivo ejecutados como programas del usuario puedan requerir privilegios especiales de tener acceso al hardware de la entrada-salida.

Se relaciona con el principio del minimality, e igualmente importante para el diseño del microkernel, la separación de mecanismo y la política, es qué permite la construcción de sistemas arbitrarios encima de un núcleo mínimo. Ninguna política incorporada al núcleo no se puede sobreescribir en el nivel de usuario y por lo tanto no limita la generalidad del microkernel. La política aplicada en servidores user-level puede ser cambiada substituyendo los servidores (o dejando el uso elegir entre los servidores competentes que ofrecen servicios similares).

Para la eficacia, la mayoría de los microkernels contienen planificadores y manejan contadores de tiempo, con violación del principio del minimality y del principio de separación del política-mecanismo.

Empezar para arriba (el Booting ) de un sistema microkernel-basado requiere los drivers de dispositivo, que no son parte del núcleo. Esto significa típicamente que están empaquetados con el núcleo en la imagen del cargador, y el núcleo apoya un protocolo del elástico de bota que defina cómo se localizan y se comienzan los conductores. Algunos microkernels simplifican esto colocando algunos conductores dominantes dentro del núcleo (con violación del principio del minimality), LynxOS y el original Minix es ejemplos. Algunos incluso incluyen un sistema de ficheros en el núcleo para simplificar el booting.

Un componente clave de un microkernel es un buen sistema del IPC . Puesto que todos los servicios son llevados a cabo por programas del usermode, los medios de la comunicación eficientes entre los programas son esenciales, lejos más tan que en núcleos monolíticos. El diseño del sistema del IPC hace o rompe un microkernel. Para ser eficaz, el sistema del IPC debe no sólo tener gastos indirectos bajos, pero también obra recíprocamente bien con la previsión de la CPU.

Funcionamiento

La obtención de un servicio es intrínsecamente más costosa en un sistema microkernel-basado que un sistema monolítico. En el sistema monolítico, el servicio es obtenido por una sola llamada de sistema, que requiere dos interruptores de modo del (cambios del nivel de privilegio del procesador). En el sistema microkernel-basado, el servicio es obtenido enviando un mensaje del IPC a un servidor, y obteniendo el resultado en otro mensaje del IPC del servidor. Esto requiere dos llamadas de sistema (un total de cuatro interruptores de modo) más dos interruptores del espacio de dirección, pues el servidor está típicamente en un diverso espacio de dirección del cliente. Además, el paso de datos reales al servidor y a la parte posterior puede incurrir en gastos indirectos de copiado del suplemento, mientras que en un sistema monolítico el núcleo puede tener acceso directo a los datos en los almacenadores intermediarios del cliente.

El funcionamiento es por lo tanto una edición potencial en sistemas del microkernel. De hecho, la experiencia de los microkernels de primera generación tales como Mach y el estribillo demostraron que los sistemas basados en ellos se realizaron muy mal. Sin embargo, el Jochen Liedtke demostró que los problemas de funcionamiento del Mach eran el resultado del diseño pobre y puesta en práctica, y específicamente la huella excesiva del escondrijo del Mach. Liedtke demostró con su propio microkernel L4 que con diseño y la puesta en práctica cuidadosos, y especialmente siguiendo el principio del minimality, los costes del IPC se podrían reducir por más que una orden de la magnitud comparada al Mach. El funcionamiento de L4 IPC es todavía insuperado a través de una gama de arquitecturas.

Mientras que estos resultados demuestran que la degradación de las prestaciones de los sistemas basados en los microkernels de primera generación no es representativa para los núcleos de segunda generación tales como L4, ésta no constituye ninguna prueba que microkernel-basó sistemas se pueda construir con buen funcionamiento. Se ha demostrado que un servidor monolítico del linux viró a los objetos expuestos L4 solamente linux nativo excesivo de arriba del alguno por ciento hacia el lado de babor. Sin embargo, tal sistema del solo-servidor exhibe poco, o ningún de las ventajas que los microkernels son supuestos proporcionar estructurando funcionalidad operating-system en los servidores separados.

Un número de sistemas multiservidores comerciales existen, particularmente el QNX de los sistemas en tiempo real y la integridad . No se ha publicado ninguna comparación comprensiva de los sistemas monolíticos en relación con del funcionamiento para esos sistemas multiservidores. Además, el funcionamiento no parece ser la preocupación de eliminación por esos sistemas comerciales, que en lugar de otro acentúan simplicidad por robustez. Una tentativa de construir un sistema operativo multiservidor de alto rendimiento era el proyecto del linux de la serrería de IBM. Sin embargo, este proyecto nunca fue terminado.

Se ha demostrado mientras tanto que los drivers de dispositivo user-level pueden venir cerca del funcionamiento de los conductores del en-núcleo incluso para tal alto-rendimiento de procesamiento, alto-interrumpe los dispositivos como Ethernet del gigabit. Esto parece implicar que los sistemas multiservidores de alto rendimiento son posibles.

Seguridad

Las ventajas de la seguridad de microkernels se han discutido con frecuencia. Sin embargo, en el contexto de la seguridad, el principio del minimality de microkernels es una consecuencia directa del principio de menos privilegio, así que significa que todo el código debe solamente tener la cantidad mínima de privilegios que necesita proporcionar su funcionalidad required. Una consecuencia directa de este principio es que la base de computación confiada en de un sistema (TCB) se debe mantener mínima. Pues el núcleo (es decir, el código que ejecuta en el modo privilegiado del hardware) es siempre parte del TCB, la reducción al mínimo de él es natural en un diseño seguridad-conducido.

Por lo tanto, los diseños del microkernel se han utilizado para los sistemas diseñados para los usos de la alto-seguridad, incluyendo el KeyKOS, el EROS y los sistemas militares. De hecho, los criterios comunes (cc) en el nivel más alto del aseguramiento (EAL7) tienen un requisito explícito que la blanco de la evaluación sea “simple”, un reconocimiento del hecho de que es prácticamente imposible establecer la fiabilidad verdadera para un sistema complejo.

El trabajo reciente sobre microkernels se está centrando en las especificaciones formales del núcleo API, y las pruebas formales de las características de seguridad del API. El primer ejemplo de esto es una prueba matemática de los mecanismos del confinamiento en EROS, basada en un modelo simplificado del EROS API. Más recientemente, un sistema comprensivo de pruebas controladas por ordenador se ha realizado de las características del modelo de la protección de la versión seL4 de L4.

Algunos proyectos van incluso más futuros, teniendo como objetivo la verificación formal completa, es decir una prueba matemática que la puesta en práctica del núcleo es constante con su especificación, que entonces proporciona una garantía que las características probaron sobre el asimiento del API realmente para el núcleo verdadero. Este grado de aseguramiento va más allá incluso de cc EAL7. Tales pruebas se están intentando para el Coyotos y seL4.

Ver también

Núcleo (de informática) Exokernel, una arquitectura del núcleo de la investigación con un más acercamiento minimalista a la tecnología del núcleo.
Núcleo híbrido
Núcleo monolítico
Núcleo modular
Nanokernel
Base de computación confiada en

.

Zenithic

Microkernel

Random links:

Tremont, Illinois | Philosophe | Brit3anico Selby | Expedientes asiáticos del hombre | Phenazopyridine