L4 (micronúcleo)

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

L4 es una familia de micronúcleos de segunda generación basada en los diseños e implementaciones originales del informático alemán Jochen Liedtke. Originalmente implementada en código ensamblador altamente afinado para procesadores Intel i386, la API ha sufrido grandes desarrollos en varias direcciones, tanto buscando un nivel más alto de independencia de plataforma como mejorando seguridad, aislamiento y robustez. Ha habido varias reimplementaciones de la interfaz binaria del núcleo L4 (ABI) y sus sucesores de más alto nivel, incluyendo L4Ka::Pistachio (Uni Karlsruhe), L4/MIPS (UNSW) y Fiasco (TU Dresden). Por esta razón, el nombre L4 ya no se refiere únicamente a la implementación original de Liedtke, sino que se aplica a toda la familia de micronúcleos que incluyen la interfaz del núcleo L4 y sus diferentes versiones.

Paradigma de diseño[editar]

Al explicar la idea de un micronúcleo, Liedtke decía:

Un concepto es tolerado dentro de un micronúcleo sólo si moviéndolo fuera de él, es decir, desarrollando implementaciones similares a nivel de usuario, la funcionalidad requerida del sistema no podría ser totalmente satisfecha.[1]

De esta manera, el micronúcleo L4 proporciona sólo cuatro mecanismos básicos: modelo de hilos, un mecanismo para comunicación entre procesos síncrona, scheduling y una abstracción del espacio de direcciones.

Un sistema operativo basado en un micronúcleo L4, tiene que proporcionar sus servicios a manera de "servidores" en espacio usuario que los núcleos monolíticos como Linux o micronúcleos de generaciones más antiguas incluyen internamente. Por ejemplo, para implementar un sistema seguro tipo Unix, los servidores tienen que proveer el manejo de permisos que Mach incluía dentro del núcleo.

Historia[editar]

Al notar los problemas de diseño y rendimiento de la primera generación del micronúcleo Mach, sus programadores se pusieron a re-examinar el concepto completo de los micronúcleos a mediados de los años 90. Se vio que la comunicación entre procesos asíncrona incluida dentro del núcleo utilizada en Mach llegó a ser una de las principales razones de su bajo rendimiento. Esto indujo a algunos de los programadores de Mach a incluir algunos componentes críticos dentro del núcleo (controladores de dispositivos o sistemas de archivos, por ejemplo), lo que ocasionaba un conflicto con el concepto minimalista de un micronúcleo real.

L3[editar]

Jochen Liedtke probó que una pequeña y bien diseñada capa de comunicación entre procesos implementada prestando atención al rendimiento y a cosas específicas de la plataforma, mejoraría el rendimiento general del núcleo. En lugar del complejo sistema de comunicación entre procesos de Mach, su micronúcleo L3 simplemente pasaba los mensajes sin agregarles ninguna carga extra. Definir e implementar las políticas de seguridad requeridas se consideró como una tarea que deberían implementar los servidores del espacio de usuario. El rol del núcleo era sólo proveer el mecanismo necesario para permitir que los servidores en el espacio de usuario, implementen y fortalezcan esas políticas. L3 probó ser un sistema operativo robusto y seguro usado por muchos años, por ejemplo por TÜV SÜD.

L4[editar]

Después de cierta experiencia usando L3, Liedtke se dio cuenta que otros conceptos de Mach también estaban mal ubicados. Al simplificar los conceptos de los micronúcleos más aún, él desarrolló el primer núclero L4 que estaba diseñado pensando principalmente en un alto rendimiento. Para incrementar absolutamente todo el rendimiento, el núcleo completo fue escrito en ensamblador. Su trabajo causó una pequeña revolución en los círculos de diseño de sistemas operativos. Pronto su trabajo estaba siendo estudiado por un número de universidad e institutos de investigación, incluyendo IBM, donde Liedtke comenzó a trabajar en 1996. En el Centro de Investigación T.J. Watson de IBM, Liedtke y sus colegas continuaron investigando sobre el L4 y sobre sistemas basados en micronúcleos en general.

L4Ka::Hazelnut[editar]

En 1999, Liedtke se hizo cargo del Grupo de Arquitecturas de Sistemas en la Universidad de Karlsruhe, donde continuó su investigación en sistemas de micronúcleos. Como prueba de concepto de que un micronúcleo de alto rendimiento podría también ser construido en un lenguage de alto nivel, el grupo desarrolló L4Ka::Hazelnut, una versión escrita en C++ del núcleo que corría en máquinas basadas en procesadores IA32 y ARM. El esfuerzo fue un éxito (el rendimiento era aún aceptable) y con su publicación las versiones del núcleo escritas en lenguaje ensamblador fueron descontinuadas.

Fiasco[editar]

Paralelamente al desarrollo de L4Ka::Hazelnut, en 1998 el grupo de sistemas operativos de la TU Dresden (Technische Universität Dresden) comenzó a desarrollar su propia implementación en C++ de la interfaz del núcleo L4, llamada Fiasco. En contraste a L4Ka::Hazelnut que no permite concurrencia en el núcleo y su sucesor L4Ka::Pistachio, que sólo permite interrupciones en el núcleo en puntos específicos predefinidos, Fiasco es totalmente "preemptible" (con excepción de operaciones atómicas extremadamente pequeñas) y alcanza una muy baja latencia de interrupción. Esto era considerado necesario porque Fiasco es usado como la base del DROPS, un sistema operativo de tiempo real, también desarrollado en TU Dresden.

Independencia de plataforma[editar]

L4Ka::Pistachio[editar]

Hasta la publicación de L4Ka::Pistachio y versiones más actuales de Fiasco, todos los micronúcleos L4 han estado inherentemente atados a la arquitectura del procesador donde se implementaban. La siguiente gran movida en el desarrollo de L4 fue el salto a una API independiente de plataforma que aún retuviera las características de alto rendimiento a pesar de su nivel de portabilidad más alto. A pesar de que los conceptos sobre los que se cimentaba el núcleo eran los mismos, la nueva API proporcionaba muchos cambios radicales a las versiones de L4 previas, incluyendo mejor soporte para sistemas multiprocesador, mayor separación entre hilos y espacios de direcciones y la introducción de bloques de control de hilos a nivel de usuario (UTCBs: User-level Thread Control Blocks) y registros virtuales. Después de publicar la nueva API de L4 (versión X.2, también conocida como Versión 4) a principios de 2001, el Grupo de Arquitectura de Sistemas en la Universidad de Karlsruhe implementó desde cero un nuevo núcleo, L4Ka::Pistachio, enfocándose en alto rendimiento como también en portabilidad.

Nuevas Versiones de Fiasco[editar]

El micronúcleo Fiasco por su parte, ha sido mejorado bastante en los últimos años. Actualmente soporta varias plataformas de hardware incluyendo x86, amd64 y varias plataformas ARM. Notablemente, una versión de Fiasco (FiascoUX) puede ejecutarse como una aplicación a nivel de usuario encima de Linux.

Fiasco implementa varias extensiones a la API L4v2. Las IPC de excepciones permiten al núcleo enviar excepciones de CPU a manejadores de excepciones en aplicaciones implementadas a nivel de usuario. En la ayuda de "hilos ajenos" es posible realizar control granular sobre llamadas a sistema. UTCBs tipo X.2 han sido también añadidas; además, Fiasco contiene mecanismos para controlar permisos de comunicación tanto como manejo de consumo de recursos a nivel de núcleo. Sobre Fiasco se ha desarrollado una colección de servicios básicos a nivel de usuario (llamados L4Env) que entre otras cosas son usados para paravirtualizar una versión actual de Linux (2.6.x) (llamada L4Linux).

Universidad de Nueva Gales del Sur y NICTA[editar]

L4 también se desarrolla en la Universidad de Nueva Gales del Sur (UNSW), donde los programadores implementaron L4 en varias plataformas de 64 bits. Su trabajo resultó en L4/MIPS y L4/Alpha, haciendo que la versión original de Liedtke se bautice retroactivamente como L4/x86. Al igual que los núcleos originales de Liedtke, los núcleos de la UNSW (escritos en una mezcla de ensamblador y C) no eran portables y cada uno tenía que ser implementado desde cero. Con la publicación del altamente portable L4Ka::Pistachio, el grupo de la UNSW abandonó sus propios núcleos y comenzó a portar L4Ka::Pistachio a otras arquitecturas, incluyendo la implementación más rápida reportada de paso de mensajes (36 ciclos en la arquitectura Itanium).[2]

El grupo también ha demostrado que los controladores de dispositivos a nivel de usuario pueden tener el mismo rendimiento que controladores implementados en el núcleo[3] y desarrollaron Wombat, una versión altamente portable de Linux en L4 que corre en procesadores x86, ARM y MIPS. En procesadores XScale, Wombat demostró que el costo de hacer conmutación de contexto era hasta 30 veces menos que en Linux nativo.[4]

Investigación y desarrollo actual[editar]

Recientemente, el grupo de la UNSW en su nuevo centro en la National ICT Australia (NICTA), hizo un "fork" de L4Ka::Pistachio y lo llamó NICTA::L4-embedded; como su nombre lo dice, pretende ser usado en sistemas comerciales embebidos y consecuentemente, los detalles de implementación hacen que el consumo de memoria sea pequeño y la complejidad reducida. La API ha sido modificada para que casi todas las llamadas al sistema sean lo bastante cortas como para no requerir puntos de "preemption" para asegurar alta respuesta en tiempo real.[5]

El grupo de NICTA ahora se enfoca en transformar a L4 en una plataforma altamente segura y confiable. Actualmente se está desarrollando una prueba formal de correctitud de la implementación.[6]

Todo esto es combinado con el desarrollo de una nueva L4 API, llamada seL4, que pretende satisfacer requerimientos de seguridad tales como los de Criterio Común. La API seL4 es representada por una especificación ejecutable[7] escrita en Haskell. Hay un proyecto similar sobre la ejecución de análisis exhaustivos de latencias en operaciones de núcleos. Trabajos adicionales están desarrollando marcos para construir sistemas componentizados sobre L4.[8]

El proyecto GNU Hurd estaba considerando adoptar el micronúcleo L4 (GNU Hurd/L4 [1]) para reemplazar a Mach, pero su nuevo diseño basado en capacidades no es compatible con L4 que no soporta capacidades. Posibles alternativas son L4.sec y Coyotos, con una marcada preferencia hacia Coyotos (su desarrollo ha sido hecho público; su especificación publicada y los esfuerzos han sido hechos para hacer que Coyotos cubra todas las necesidades de HURD).

Osker [2], un sistema operativo escrito en Haskell, está siendo escrito para cumplir la especificación de L4, a pesar de que se enfoca en el uso de programación funcional para el desarrollo de sistemas operativos, no se enfoca estrictamente en investigación sobre micronúcleos.

Implantación Comercial[editar]

En noviembre de 2005, NICTA anunció que Qualcomm estaba implementando la versión de L4 de NICTA en los chips de sus Mobile Station Modem, lo que condujo al uso de L4 en algunos teléfonos móviles desde finales de 2006. En agosto de 2006, el jefe de ERTOS y profesor de la UNSW, Gernot Heiser, lanzó una compañía llamada Open Kernel Labs (OK Labs) que se encargaría de proporcionar soporte comercial a los usuarios de L4 y a continuar el desarrollo de L4 para su uso comercial, en una estrecha colaboración con NICTA. OK Labs distribuye su propia versión de L4, llamada OKL4, que es un descendiente de NICTA::L4-embedded y es soportado para x86, ARM and MIPS. OKL4 fue inicialmente distribuido bajo una licencia BSD; pero las últimas publicaciones usan una licencia dual con una licencia Sleepycat de código abierto. OK Labs también distribuye un Linux paravirtualizado llamado OKLinux, un descendiente de Wombat.

En abril de 2008, OK Labs publicó su OKL4 2.1 que es la primera versión pública de L4 usando un modelo de seguridad basado en capacidades.

Referencias[editar]

  1. Jochen Liedtke (December 1995). «On µ-Kernel Construction». Proc. 15th ACM symposium on Operating Systems Principles (SOSP). pp. 237–250. 
  2. Gray, Charles; Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; Heiser, Gernot (April 2005). «Itanium—a system implementor's tale». USENIX Annual Technical Conference. Annaheim, CA, USA. pp. 264–278. 
  3. Leslie, Ben; Chubb, Peter; FitzRoy-Dale, Nicholas; Götz, Stefan; Gray, Charles; Macpherson, Luke; Potts, Daniel; Shen, Yueting; Elphinstone, Kevin; Heiser, Gernot (September 2005). «User-level device drivers: achieved performance». Journal of Computer Science and Technology 5 (20):  pp. 654–664. doi:10.1007/s11390-005-0654-4. 
  4. van Schaik, Carl; Heiser, Gernot (January 2007). «High-performance microkernels and virtualisation on ARM and segmented architectures». 1st International Workshop on Microkernels for Embedded Systems. Sydney, Australia: NICTA. pp. 11–21. 
  5. Ruocco, Sergio (October 2008). «A Real-Time Programmer's Tour of General-Purpose L4 Microkernels». EURASIP Journal on Embedded Systems, Special Issue on Operating System Support for Embedded Real-Time Applications 2008:  pp. 1. doi:10.1155/2008/234710. http://www.hindawi.com/getarticle.aspx?doi=10.1155/2008/234710. 
  6. Tuch, Harvey; Klein, Gerwin; Norrish, Michael (January 2007). «Types, bytes, and separation logic». 34th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages. Nice, France. pp. 97–108. 
  7. Derrin, Philip; Elphinstone, Kevin; Klein, Gerwin; Cock; David; Chakravarty, Manuel M. T. (September 2006). «Running the manual: an approach to high-assurance microkernel development». ACM SIGPLAN Haskell Workshop. Portland, Oregon. pp. 60–71. 
  8. Kuz, Ihor; Liu, Yan; Gorton, Ian; Heiser, Gernot (to appear). «CAmkES: a component model for secure microkernel-based embedded systems». Journal of Systems and Software. 

Enlaces externos[editar]