Minix 3 es un pequeño sistema operativo similar a Unix . Se publica bajo una licencia BSD-3-Clause [a] y es un proyecto sucesor de las versiones anteriores, Minix 1 y 2. [1]
El principal objetivo del proyecto es que el sistema sea tolerante a fallos detectando y reparando sus fallos sobre la marcha, sin intervención del usuario. Se prevé que los principales usos del sistema sean los sistemas integrados y la educación. [2]
A partir de 2017 [actualizar], Minix 3 admite procesadores de arquitectura IA-32 y ARM . [3] También puede ejecutarse en emuladores o máquinas virtuales , como Bochs , [4] [5] VMware Workstation , [6] Microsoft Virtual PC , [7] Oracle VirtualBox , [8] y QEMU . Se está desarrollando una adaptación a la arquitectura PowerPC . [9] La distribución viene en un CD en vivo y no admite la instalación USB en vivo . [10] El proyecto ha estado inactivo desde 2018, [11] y la última versión es 3.4.0 rc6 de 2017, [12] aunque el grupo de discusión de Minix 3 todavía está activo. [13]
Se cree que Minix 3 inspiró el sistema operativo Intel Management Engine (ME) que se encuentra en el Platform Controller Hub de Intel , comenzando con la introducción de ME 11, que se utiliza con los procesadores Skylake y Kaby Lake . [14] [15] Se debatió que Minix podría haber sido el sistema operativo más utilizado en procesadores x86 / AMD64 , con más instalaciones que Microsoft Windows, Linux o macOS , debido a su uso en Intel ME. [dieciséis]
Reflexionando sobre la naturaleza de los sistemas monolíticos basados en kernel, donde un controlador (que tiene, según el creador de Minix, Tanenbaum , aproximadamente entre 3 y 7 veces más errores que un programa normal) [17] puede hacer caer todo el sistema, [18] Minix 3 tiene como objetivo crear un sistema operativo que sea un "clon de Unix multiservidor confiable y autorreparable". [19]
Para lograrlo, el código que se ejecuta en el kernel debe ser mínimo, con el servidor de archivos, el servidor de procesos y cada controlador de dispositivo ejecutándose como procesos separados en modo de usuario. Cada conductor es monitoreado cuidadosamente por una parte del sistema llamada servidor de reencarnación . Si un controlador no responde a los pings de este servidor, se cierra y se reemplaza por una copia nueva del controlador.
En un sistema monolítico, un error en un controlador puede bloquear fácilmente todo el núcleo. Es mucho menos probable que esto ocurra en Minix 3. [20]
Minix 3 fue anunciado públicamente el 24 de octubre de 2005 por Andrew Tanenbaum durante su discurso de apertura en la conferencia de Principios de Sistemas Operativos del Simposio de la Asociación de Maquinaria de Computación (ACM). Aunque todavía sirve como ejemplo para la nueva edición del libro de texto de Tanenbaum y Woodhull, está completamente rediseñado para que sea "utilizable como un sistema serio en computadoras integradas y con recursos limitados y para aplicaciones que requieren alta confiabilidad".
Publicado inicialmente bajo la misma licencia BSD-3-Clause bajo la cual Minix tenía licencia desde 2000. [23] [24] A finales de 2005, se cambió el propietario de los derechos de autor y se agregó una cuarta cláusula. [1] [25] [28]
Uno de los principales objetivos de Minix 3 es la fiabilidad. A continuación, se analizan algunos de los principios más importantes que mejoran su confiabilidad.
Los sistemas operativos monolíticos como Linux y FreeBSD y los híbridos como Windows tienen millones de líneas de código del kernel . Por el contrario, Minix 3 tiene alrededor de 6.000 líneas de código de núcleo ejecutable, [29] lo que puede hacer que los problemas sean más fáciles de encontrar en el código.
En los núcleos monolíticos, los controladores de dispositivos residen en el núcleo. Por lo tanto, cuando se instala un nuevo periférico, se inserta en el kernel código desconocido y que no es de confianza. Una línea de código incorrecta en un controlador puede provocar la caída del sistema.
En cambio, en Minix 3, cada controlador de dispositivo es un proceso de modo de usuario independiente. Los controladores no pueden ejecutar instrucciones privilegiadas, cambiar las tablas de páginas , realizar entradas/salidas (E/S) arbitrarias ni escribir en la memoria absoluta. Deben realizar llamadas al kernel para estos servicios y el kernel verifica la autoridad de cada llamada.
En los núcleos monolíticos, un controlador puede escribir en cualquier palabra de la memoria y, por tanto, dañar accidentalmente los programas del usuario.
En Minix 3, cuando un usuario espera datos de, por ejemplo, el sistema de archivos, crea un descriptor que indica quién tiene acceso y en qué direcciones. Luego pasa un índice de este descriptor al sistema de archivos, que puede pasarlo a un controlador. Luego, el sistema de archivos o el controlador le pide al kernel que escriba a través del descriptor, lo que les imposibilita escribir en direcciones fuera del búfer.
Eliminar la referencia a un puntero incorrecto dentro de un controlador bloqueará el proceso del controlador, pero no tendrá ningún efecto en el sistema en su conjunto. El servidor de reencarnación reiniciará el controlador bloqueado automáticamente. Los usuarios no notarán la recuperación de algunos controladores (p. ej., disco y red), pero sí de otros (p. ej., audio e impresora). En los núcleos monolíticos, eliminar la referencia a un puntero incorrecto en un controlador normalmente provoca un fallo del sistema.
Si un controlador entra en un bucle infinito , el programador reducirá gradualmente su prioridad hasta que quede inactivo. Con el tiempo, el servidor de reencarnación verá que no responde a las solicitudes de estado, por lo que cerrará y reiniciará el controlador del bucle. En un núcleo monolítico, un controlador en bucle podría bloquear el sistema.
Minix 3 utiliza mensajes de longitud fija para la comunicación interna, lo que elimina ciertos desbordamientos del búfer y problemas de gestión del búfer. Además, muchos exploits funcionan desbordando un búfer para engañar al programa para que regrese de una llamada a función usando una dirección de retorno de pila sobrescrita que apunta a la memoria controlada por el atacante, generalmente el búfer desbordado. En Minix 3, este ataque se mitiga porque el espacio de instrucciones y datos se divide y solo se puede ejecutar código en el espacio de instrucciones (solo lectura), lo que se denomina protección del espacio ejecutable . Sin embargo, esta mitigación no previene los ataques que dependen de la ejecución de memoria legítimamente ejecutable de forma maliciosa ( retorno a libc , programación orientada al retorno ).
Los controladores de dispositivos obtienen servicios del kernel (como copiar datos a los espacios de direcciones de los usuarios) realizando llamadas al kernel. El kernel Minix 3 tiene un mapa de bits para cada controlador que especifica qué llamadas está autorizado a realizar. En los núcleos monolíticos, cada controlador puede llamar a todas las funciones del núcleo, autorizadas o no.
El kernel también mantiene una tabla que indica a qué puertos de E/S puede acceder cada controlador. Por lo tanto, un controlador sólo puede tocar sus propios puertos de E/S. En los núcleos monolíticos, un controlador con errores puede acceder a los puertos de E/S que pertenecen a otro dispositivo.
No todos los controladores y servidores necesitan comunicarse con todos los demás controladores y servidores. En consecuencia, un mapa de bits por proceso determina a qué destinos puede enviar cada proceso.
Un proceso especial, llamado servidor de reencarnación, hace ping periódicamente a cada controlador de dispositivo. Si el controlador muere o no responde correctamente a los pings, el servidor de reencarnación lo reemplaza automáticamente con una copia nueva. La detección y sustitución de controladores que no funcionan es automática y no es necesaria ninguna acción por parte del usuario. Esta característica no funciona actualmente con los controladores de disco, pero en la próxima versión el sistema podrá recuperar incluso los controladores de disco, que estarán ocultos en la memoria de acceso aleatorio (RAM). La recuperación del controlador no afecta los procesos en ejecución.
Cuando ocurre una interrupción , se convierte en un nivel bajo en una notificación enviada al controlador apropiado. Si el conductor está esperando un mensaje, recibe la interrupción inmediatamente; de lo contrario, recibirá la notificación la próxima vez que reciba RECEIVEun mensaje. Este esquema elimina las interrupciones anidadas y facilita la programación del controlador.
Como puede verse, en el nivel inferior se encuentra el microkernel , que son unas 4.000 líneas de código (principalmente en C , más una pequeña cantidad de lenguaje ensamblador ). Maneja interrupciones , programación y paso de mensajes. También admite una interfaz de programación de aplicaciones (API) de aproximadamente 30 llamadas al kernel que pueden realizar servidores y controladores autorizados. Los programas de usuario no pueden realizar estas llamadas. En cambio, pueden emitir llamadas al sistema POSIX que envían mensajes a los servidores. Las llamadas al kernel realizan funciones como configurar interrupciones y copiar datos entre espacios de direcciones.
En el siguiente nivel, están los controladores de dispositivo , cada uno de los cuales se ejecuta como un proceso de usuario independiente . Cada uno controla algún dispositivo de E/S, como un disco o una impresora. Los controladores no tienen acceso al espacio del puerto de E/S y no pueden emitir instrucciones de E/S directamente. En cambio, deben realizar llamadas al kernel que proporcionen una lista de puertos de E/S en los que escribir y los valores que se escribirán. Si bien hay una pequeña cantidad de sobrecarga al hacer esto (normalmente 500 ns), este esquema hace posible que el núcleo verifique la autorización, de modo que, por ejemplo, el controlador de audio no pueda escribir en el disco.
En el siguiente nivel están los servidores . Aquí es donde se encuentran casi todas las funciones del sistema operativo. Los procesos de usuario obtienen servicios de archivos, por ejemplo, enviando mensajes al servidor de archivos para abrir, cerrar, leer y escribir archivos. A su vez, el servidor de archivos realiza la E/S del disco enviando mensajes al controlador de disco, que controla el disco.
Uno de los servidores clave es el servidor de reencarnación. Su trabajo es sondear todos los demás servidores y controladores para comprobar su estado periódicamente. Si un componente no responde correctamente, sale o entra en un bucle infinito , el servidor de reencarnación (que es el proceso principal de los controladores y servidores) elimina el componente defectuoso y lo reemplaza con una copia nueva. De esta manera, el sistema se recupera automáticamente sin interferir con los programas en ejecución.
Actualmente, el servidor de reencarnación, el servidor de procesos y el microkernel forman parte de la base informática confiable . Si alguno de ellos falla, el sistema colapsa. Sin embargo, reducir la base informática confiable de 3 a 5 millones de líneas de código, como en los sistemas Linux y Windows, a aproximadamente 20.000 líneas mejora en gran medida la confiabilidad del sistema. [ cita necesaria ]
Minix 1.0, 1.5 y 2.0 se desarrollaron como herramientas para ayudar a las personas a aprender sobre el diseño de sistemas operativos.
Minix 1.0, lanzado en 1987, tenía 12.000 líneas de C y algo de lenguaje ensamblador x86 . El código fuente del kernel, el administrador de memoria y el sistema de archivos de Minix 1.0 están impresos en el libro. Tanenbaum desarrolló originalmente Minix para que fuera compatible con las microcomputadoras IBM PC y IBM PC/AT disponibles en ese momento.
Minix 1.5, lanzado en 1991, incluía soporte para sistemas MicroChannel IBM PS/2 y también fue portado a las arquitecturas Motorola 68000 y SPARC , soportando las plataformas informáticas Atari ST , Commodore Amiga , Apple Macintosh y Sun Microsystems SPARCstation . También estaba disponible una versión de Minix que se ejecuta como proceso de usuario en SunOS .
Minix 2.0, lanzado en 1997, sólo estaba disponible para las arquitecturas SPARC alojadas en x86 y Solaris . Minix-vmd fue creado por dos investigadores de la Vrije Universiteit y agregó memoria virtual y soporte para el sistema X Window .
Minix 3 hace lo mismo y proporciona un sistema operativo moderno con muchas herramientas más nuevas y muchas aplicaciones Unix . [30] El Prof. Tanenbaum dijo una vez:
Tenga en cuenta que MINIX 3 no es el MINIX de su abuelo... MINIX 1 fue escrito como una herramienta educativa... MINIX 3 es eso, además de un comienzo en la construcción de un sistema operativo altamente confiable, autocurativo y libre de sobrecargas... MINIX 1 y MINIX 3 están relacionados de la misma manera que Windows 3.1 y Windows XP : el mismo nombre. [19]
También se han realizado muchas mejoras en la estructura del kernel desde el lanzamiento de Minix 2, lo que hace que el sistema sea más confiable. [31] La versión 3.1.5 de Minix se lanzó el 5 de noviembre de 2009. Contiene X11 , Emacs , vi , cc, GCC , Perl , Python , Almquist shell , Bash , Z shell , cliente FTP , cliente SSH , cliente Telnet , Pine y Más de 400 otros programas de utilidad comunes de Unix. Con la incorporación de X11, esta versión marca la transición desde un sistema de solo texto. Otra característica de esta versión, que se mejorará en futuras versiones, es la capacidad del sistema para soportar fallas de los controladores de dispositivos y, en muchos casos, reemplazarlos automáticamente sin afectar los procesos en ejecución. De esta manera, Minix se repara automáticamente y puede usarse en aplicaciones que exigen alta confiabilidad.
Minix 3.2.0 se lanzó en febrero de 2012. Esta versión tiene muchas características nuevas, incluido el compilador Clang , compatibilidad con multiprocesamiento simétrico experimental , compatibilidad con sistemas de archivos procfs y ext2fs y GNU Debugger (GDB). Varias partes de NetBSD también están integradas en la versión, incluido el gestor de arranque, libc y varias utilidades y otras bibliotecas . [32]
Minix 3.3.0 se lanzó en septiembre de 2014. Esta versión es la primera versión que admite la arquitectura ARM además de x86. También es compatible con un espacio de usuario de NetBSD , con miles de paquetes de NetBSD ejecutándose desde el primer momento.
Rocky Raccoon es la mascota de Minix 3. [33]
MINIXCon es una conferencia para compartir charlas, esfuerzos e investigaciones relacionadas con Minix.
Se llevó a cabo una vez en 2016. MINIXCon2017 fue cancelada por falta de charlas presentadas. [34] [35]
De la sección
Rebirth
: "Varios estudios han demostrado que el software contiene en términos generales entre 6 y 16 errores por cada 1000 líneas de código y que los controladores de dispositivos tienen entre 3 y 7 veces más errores que el resto del sistema operativo. Cuando se combina con el hecho de que El 70% de un sistema operativo típico consta de controladores de dispositivos, está claro que los controladores de dispositivos son una gran fuente de problemas. Para
Windows XP
, el 85% de los fallos se deben a errores en los controladores de dispositivos. Obviamente, para hacer que los sistemas operativos sean confiables, algo. "Hay que hacer para lidiar con los controladores de dispositivos defectuosos. Construir un sistema confiable a pesar de los errores inevitables en los controladores de dispositivos fue la fuerza impulsora original detrás de Minix 3".
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
{{cite web}}: Mantenimiento CS1: bot: estado de la URL original desconocido ( enlace )