Minix 3 es un sistema operativo pequeño, 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 objetivo principal del proyecto es que el sistema sea tolerante a fallos , detectando y reparando sus fallos sobre la marcha, sin intervención del usuario. Los principales usos del sistema están previstos para sistemas embebidos y 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 un puerto para 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 usa 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. [16]
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 3 a 7 veces más errores que un programa normal) [17] puede hacer caer todo el sistema, [18] Minix 3 apunta a crear un sistema operativo que sea un "clon de Unix confiable, autocurativo y multiservidor". [19]
Para lograrlo, el código que se ejecuta en el núcleo debe ser mínimo, y el servidor de archivos, el servidor de procesos y cada controlador de dispositivo deben ejecutarse como procesos separados en modo usuario. Cada controlador es monitoreado cuidadosamente por una parte del sistema denominada servidor de reencarnación . Si un controlador no responde a los pings de este servidor, se apaga y se reemplaza por una copia nueva del controlador.
En un sistema monolítico, un error en un controlador puede hacer que todo el núcleo se bloquee fácilmente. Esto es mucho menos probable que ocurra en Minix 3. [20]
El Minix 3 fue anunciado públicamente el 24 de octubre de 2005 por Andrew Tanenbaum durante su discurso inaugural en la conferencia sobre Principios de Sistemas Operativos del Simposio de la Association for Computing Machinery (ACM). Aunque todavía sirve como ejemplo para la nueva edición del libro de texto de Tanenbaum y Woodhull, ha sido rediseñado de manera integral para que sea "utilizable como un sistema serio en computadoras integradas y con recursos limitados y para aplicaciones que requieran alta confiabilidad".
Inicialmente publicado bajo la misma licencia BSD-3-Clause bajo la cual Minix estuvo licenciado desde 2000. [23] [24] A fines 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 fiabilidad.
Los sistemas operativos monolíticos como Linux y FreeBSD y los híbridos como Windows tienen millones de líneas de código de núcleo . En cambio, Minix 3 tiene alrededor de 6.000 líneas de código de núcleo ejecutable, [29] lo que puede facilitar la detección de problemas 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 núcleo un código desconocido y no confiable. Una línea de código incorrecta en un controlador puede hacer que el sistema se caiga.
En cambio, en Minix 3, cada controlador de dispositivo es un proceso independiente en modo usuario. Los controladores no pueden ejecutar instrucciones privilegiadas, cambiar las tablas de páginas , realizar entradas y salidas arbitrarias (E/S) o escribir en la memoria absoluta. Deben realizar llamadas al núcleo para estos servicios y el núcleo verifica cada llamada para comprobar su autoridad.
En los núcleos monolíticos, un controlador puede escribir en cualquier palabra de la memoria y así dañar accidentalmente los programas del usuario.
En Minix 3, cuando un usuario espera datos, por ejemplo, del 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. El sistema de archivos o el controlador solicitan entonces al núcleo que escriba a través del descriptor, lo que hace imposible que escriban en direcciones fuera del búfer.
La anulación de la referencia de un puntero defectuoso dentro de un controlador provocará un bloqueo del proceso del controlador, pero no tendrá ningún efecto en el sistema en su conjunto. El servidor de reincarnación reiniciará automáticamente el controlador dañado. Los usuarios no notarán la recuperación de algunos controladores (por ejemplo, de disco y de red), pero es posible que sí lo hagan en otros (por ejemplo, de audio e impresora). En los núcleos monolíticos, la anulación de la referencia de un puntero defectuoso en un controlador normalmente provoca un bloqueo del sistema.
Si un controlador entra en un bucle infinito , el programador reducirá gradualmente su prioridad hasta que quede inactivo. Finalmente, el servidor de reincarnación verá que no está respondiendo a las solicitudes de estado, por lo que matará y reiniciará el controlador en 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 de búfer y problemas de gestión de búfer. Además, muchos exploits funcionan desbordando un búfer para engañar al programa para que regrese de una llamada de función utilizando 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 el código en el espacio de instrucciones (de solo lectura), lo que se denomina protección del espacio ejecutable . Sin embargo, los ataques que se basan en ejecutar memoria legítimamente ejecutable de forma maliciosa ( retorno a libc , programación orientada al retorno ) no se previenen con esta mitigación.
Los controladores de dispositivos obtienen servicios del núcleo (como copiar datos a los espacios de direcciones de los usuarios) al realizar llamadas al núcleo. El núcleo 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 núcleo también mantiene una tabla que indica a qué puertos de E/S puede acceder cada controlador. Por lo tanto, un controlador solo puede acceder a 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. Por lo tanto, un mapa de bits por proceso determina a qué destinos puede enviar cada proceso.
Un proceso especial, llamado servidor de reencarnación, envía un ping periódico a cada controlador de dispositivo. Si el controlador deja de funcionar o no responde correctamente a los pings, el servidor de reencarnación lo reemplaza automáticamente con una copia nueva. La detección y el reemplazo de controladores que no funcionan es automático, sin necesidad de que el usuario realice ninguna acción. Esta característica no funciona para los controladores de disco en la actualidad, pero en la próxima versión el sistema podrá recuperar incluso los controladores de disco, que se almacenarán en la memoria de acceso aleatorio (RAM). La recuperación de controladores no afecta a los procesos en ejecución.
Cuando se produce una interrupción , se convierte a un nivel bajo en una notificación enviada al controlador correspondiente. Si el controlador está esperando un mensaje, recibe la interrupción inmediatamente; de lo contrario, recibe la notificación la próxima vez que realiza una operación RECEIVEpara obtener un mensaje. Este esquema elimina las interrupciones anidadas y facilita la programación del controlador.
Como se puede ver, en el nivel inferior se encuentra el microkernel , que tiene unas 4.000 líneas de código (en su mayoría en C , más una pequeña cantidad de lenguaje ensamblador ). Maneja las interrupciones , la programación y el paso de mensajes. También admite una interfaz de programación de aplicaciones (API) de unas 30 llamadas al kernel que pueden realizar los 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 establecer interrupciones y copiar datos entre espacios de direcciones.
En el siguiente nivel superior, están los controladores de dispositivos , cada uno de los cuales se ejecuta como un proceso independiente en el espacio de usuario . 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 su lugar, deben realizar llamadas al núcleo que proporcionen una lista de puertos de E/S en los que escribir y los valores que se deben escribir. Si bien esto implica una pequeña cantidad de sobrecarga (normalmente 500 ns), este esquema permite 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 se encuentran los servidores . Aquí es donde se encuentra casi toda la funcionalidad del sistema operativo. Los procesos de usuario obtienen el servicio 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 del disco, que controla el disco.
Uno de los servidores clave es el servidor de reencarnación. Su trabajo es sondear a todos los demás servidores y controladores para verificar su estado periódicamente. Si un componente no responde correctamente, se cierra o entra en un bucle infinito , el servidor de reencarnación (que es el proceso padre de los controladores y servidores) elimina el componente defectuoso y lo reemplaza con una copia nueva. De esta manera, el sistema se autocura 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 se bloquea. 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 enormemente la confiabilidad del sistema. [ cita requerida ]
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, publicado en 1987, tenía 12.000 líneas de C y algo de lenguaje ensamblador x86 . El código fuente del núcleo, 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 e IBM PC/AT disponibles en ese momento.
Minix 1.5, lanzado en 1991, incluía soporte para sistemas IBM PS/2 de MicroChannel y también fue adaptado a las arquitecturas Motorola 68000 y SPARC , y era compatible con 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 ejecutaba como un 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 profesor 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 más un comienzo para construir un sistema operativo altamente confiable, autocurativo y libre de hinchazón... MINIX 1 y MINIX 3 están relacionados de la misma manera que Windows 3.1 y Windows XP : mismo nombre. [19]
También se han realizado muchas mejoras en la estructura del núcleo desde el lanzamiento de Minix 2, haciendo 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 Unix comunes. Con la adició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, es la capacidad del sistema para soportar fallas de controladores de dispositivos y, en muchos casos, reemplazarlos automáticamente sin afectar los procesos en ejecución. De esta manera, Minix se autocura y se puede usar en aplicaciones que exigen alta confiabilidad.
Minix 3.2.0 fue lanzado en febrero de 2012. Esta versión tiene muchas características nuevas, incluyendo el compilador Clang , soporte experimental para multiprocesamiento simétrico , soporte para sistemas de archivos procfs y ext2fs , y GNU Debugger (GDB). Varias partes de NetBSD también están integradas en la versión, incluyendo 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 que admite la arquitectura ARM además de x86. También admite un espacio de usuario NetBSD , con miles de paquetes NetBSD que se ejecutan de inmediato.
Rocky Raccoon es la mascota de Minix 3. [33]
MINIXCon es una conferencia para compartir charlas, esfuerzos e investigaciones relacionadas con Minix.
Se celebró una vez en 2016. MINIXCon2017 se canceló debido a la falta de charlas presentadas. [34] [35]
De la sección
Renacimiento
: "Varios estudios han demostrado que el software contiene en líneas generales algo así como 6-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 consiste en 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 que los sistemas operativos sean fiables, hay que hacer algo para solucionar los controladores de dispositivos con errores. Construir un sistema fiable a pesar de los inevitables errores 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}}: CS1 maint: bot: estado de URL original desconocido ( enlace )