Minix 3 es un proyecto para crear un sistema operativo pequeño, de alta disponibilidad y alto funcionamiento similar a Unix . Se publica bajo una licencia BSD y es un proyecto sucesor de las versiones anteriores, Minix 1 y 2.
Desarrollador | Andrew S. Tanenbaum |
---|---|
Escrito en | C , lenguaje ensamblador |
Familia OS | Tipo Unix |
Estado de trabajo | Abandonado |
Modelo fuente | Fuente abierta |
Versión inicial | 24 de octubre de 2005 |
Repositorio | |
Objetivo de marketing | Sistemas integrados , educación |
Disponible en | inglés |
Plataformas | IA-32 , BRAZO |
Tipo de grano | Microkernel |
Userland | MINIX, NetBSD |
Interfaz de usuario predeterminada | ceniza |
Licencia | licencia permisiva personalizada |
Precedido por | Minix 1.0, 1.5 y 2.0 |
Página web oficial | www |
El objetivo principal del proyecto es que el sistema sea tolerante a fallas detectando y reparando sus propias fallas sobre la marcha, sin la intervención del usuario. Se prevé que los principales usos del sistema sean sistemas integrados y educación. [1]
A partir de 2017 [actualizar], MINIX 3 admite procesadores de arquitectura IA-32 y ARM . [2] También se puede ejecutar en emuladores o máquinas virtuales , como Bochs , [3] [4] VMware Workstation , [5] Microsoft Virtual PC , [6] Oracle VirtualBox , [7] y QEMU . Se está desarrollando una adaptación a la arquitectura PowerPC . [8]
La distribución viene en un CD en vivo y se puede descargar como una imagen de memoria USB en vivo . [9] La última versión es "minix_R3.4.0rc6-d5e4fc0.iso.bz2" (9 de mayo de 2017). [10]
Se cree que MINIX 3 se usa en Intel Management Engine (ME) que se encuentra en el Platform Controller Hub de Intel a partir de la introducción de ME 11, que se usa con los procesadores Skylake y Kaby Lake . [11] [12]
Su uso en Intel ME podría convertirlo en el sistema operativo más utilizado en procesadores x86 / AMD64 a partir de 2015 [actualizar], con más instalaciones que Microsoft Windows, Linux o macOS. [13]
Objetivos del proyecto
Reflexionando sobre la naturaleza de los sistemas basados en kernel monolíticos , donde un controlador (que, según el creador de MINIX, Tanenbaum , tiene aproximadamente de 3 a 7 veces más errores que un programa habitual) [14] puede derribar todo el sistema, [15] MINIX 3 tiene como objetivo crear un sistema operativo que sea un "clon Unix confiable, autorreparable y multiservidor". [dieciséis]
Para lograr eso, 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 apaga 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 kernel. Es mucho menos probable que esto ocurra en MINIX 3. [17]
Historia
Versión | Fecha de lanzamiento | Descripción |
---|---|---|
3.1.0 | 2005-10-24 |
|
3.1.2a | 2006-05-29 |
|
3.1.3 | 2007-04-13 |
|
3.1.3a | 2007-06-08 |
|
3.1.4 | 2009-06-09 |
|
3.1.5 | 2009-11-05 |
|
3.1.6 | 2010-02-08 |
|
3.1.7 | 2010-06-16 |
|
3.1.8 | 2010-10-04 |
|
3.2.0 | 2012-02-29 |
|
3.2.1 | 2013-02-21 |
|
3.3.0 [20] | 2014-09-15 |
|
3.4.0 rc6 | 2017-05-09 | ? |
|
MINIX 3 fue anunciado públicamente el 24 de octubre de 2005 por Andrew Tanenbaum durante su discurso de apertura en la parte superior de 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, se ha rediseñado de manera integral para que sea "utilizable como un sistema serio en computadoras integradas y con recursos limitados y para aplicaciones que requieren alta confiabilidad".
Políticas de confiabilidad
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.
Reducir el tamaño del grano
Los sistemas operativos monolíticos como Linux y FreeBSD e híbridos como Windows tienen millones de líneas de código de kernel . En contraste, MINIX 3 tiene alrededor de 6.000 líneas de código de kernel ejecutable, [21] lo que puede hacer que los problemas sean más fáciles de encontrar en el código.
Enjaula a los bichos
En los núcleos monolíticos, los controladores de dispositivo residen en el núcleo. Por lo tanto, cuando se instala un nuevo periférico, se inserta un código desconocido y no confiable en el kernel. Una línea incorrecta de código en un controlador puede hacer que el sistema se caiga.
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 arbitrarias (E / S) o escribir en la memoria absoluta. Deben realizar llamadas al kernel para estos servicios y el kernel verifica cada llamada para obtener autoridad.
Limite el acceso a la memoria de los conductores
En los núcleos monolíticos, un controlador puede escribir en cualquier palabra de la memoria y, por lo tanto, corromper 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 a este descriptor al sistema de archivos, que puede pasarlo a un controlador. El sistema de archivos o el controlador le pide al kernel que escriba a través del descriptor, lo que hace imposible que escriban en direcciones fuera del búfer.
Sobrevive a los malos consejos
Desreferenciar 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 averiado automáticamente. Los usuarios no notarán la recuperación para algunos controladores (por ejemplo, disco y red), pero sí para otros (por ejemplo, audio e impresora). En los núcleos monolíticos, eliminar la referencia a un puntero incorrecto en un controlador normalmente conduce a un bloqueo del sistema.
Domesticar bucles infinitos
Si un controlador entra en un bucle infinito , el programador reducirá gradualmente su prioridad hasta que quede inactivo. Finalmente, el servidor de reencarnación verá que no responde a las solicitudes de estado, por lo que matará y reiniciará el controlador de bucle. En un kernel monolítico, un controlador de bucle podría bloquear el sistema.
Limite el daño por desbordamientos de búfer
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 invadiendo un búfer para engañar al programa para que regrese de una llamada a función utilizando una dirección de retorno de pila sobrescrita que apunta a la memoria controlada por el atacante, generalmente el búfer de saturación. En MINIX 3, este ataque se mitiga porque las instrucciones y el espacio de datos se dividen y solo se puede ejecutar el 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 se basan en ejecutar memoria legítimamente ejecutable de una manera maliciosa ( retorno a libc , programación orientada al retorno ).
Restringir el acceso a las funciones del kernel
Los controladores de dispositivos obtienen servicios del kernel (como copiar datos en los espacios de direcciones de los usuarios) al realizar llamadas al kernel. El kernel de 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.
Restringir el acceso a los puertos de E / S
El kernel también mantiene una tabla que indica a qué puertos de E / S puede acceder cada controlador. Por lo tanto, un controlador solo 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.
Restringir la comunicación con los componentes del sistema operativo
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.
Reencarnar conductores muertos o enfermos
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, sin necesidad de que el usuario realice ninguna acción. Esta función 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 sombrearán en la memoria de acceso aleatorio (RAM). La recuperación del controlador no afecta los procesos en ejecución.
Integrar interrupciones y mensajes
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, recibe la notificación la próxima vez que lo haga RECEIVE
para recibir un mensaje. Este esquema elimina las interrupciones anidadas y facilita la programación del controlador.
Arquitectura
Como se puede ver, en el nivel inferior está el microkernel , que tiene aproximadamente 4.000 líneas de código (principalmente en C , más una pequeña cantidad de lenguaje ensamblador ). Maneja interrupciones , programación y transmisión de mensajes. También es compatible con una interfaz de programación de aplicaciones (API) de aproximadamente 30 llamadas al kernel que pueden realizar los servidores y controladores autorizados. Los programas de usuario no pueden realizar estas llamadas. En su lugar, 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 dispositivos , cada uno de los cuales se ejecuta como un proceso de área 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 su lugar, deben realizar llamadas al kernel dando una lista de puertos de E / S en los que escribir y los valores que se escribirán. Si bien hay una pequeña sobrecarga al hacer esto (típicamente 500 ns), este esquema hace posible que el kernel 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 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 obtiene E / S de disco mediante el envío de mensajes al controlador de disco, que controla el disco.
Uno de los servidores clave es el servidor de la reencarnación. Su trabajo es sondear todos los demás servidores y controladores para verificar su estado periódicamente. Si un componente no responde correctamente, o 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 autocura automáticamente sin interferir con los programas en ejecución.
Actualmente, el servidor de reencarnación, el servidor de procesos y el microkernel son parte de la base informática confiable . Si alguno de ellos falla, el sistema falla. No obstante, la reducción de la base informática confiable de 3-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 ]
Diferencias entre MINIX 3 y versiones anteriores
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 compatibilidad 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 adaptado 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 ejecutaba como un proceso de usuario bajo SunOS .
MINIX 2.0, lanzado en 1997, solo estaba disponible para las arquitecturas SPARC alojadas en x86 y Solaris . Minix-vmd fue creado por dos investigadores de 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 . [22] 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 en la construcción de un sistema operativo altamente confiable, autocurativo y sin hinchazón ... MINIX 1 y MINIX 3 están relacionados de la misma manera que Windows 3.1 y Windows XP son: mismo nombre. [dieciséis]
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. [23] MINIX versión 3.1.5 fue lanzada 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 de un sistema de solo texto. Otra característica de esta versión, que se mejorará en las futuras, es la capacidad del sistema para resistir fallas de controladores de dispositivos y, en muchos casos, reemplazarlos automáticamente sin afectar los procesos en ejecución. De esta forma, MINIX es autorreparable y se puede utilizar en aplicaciones que exigen una alta fiabilidad.
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 depurador GNU (GDB). Varias partes de NetBSD también están integradas en la versión, incluido el cargador de arranque, libc y varias utilidades y otras bibliotecas . [24]
MINIX 3.3.0 se lanzó en septiembre de 2014. Esta versión es la primera versión compatible con la arquitectura ARM además de x86. También es compatible con un área de usuario de NetBSD , con miles de paquetes NetBSD que se ejecutan desde el primer momento.
Mascota
Rocky Raccoon es la mascota de MINIX 3. [25]
MINIXCon
MINIXCon es una conferencia sobre el intercambio de charlas, esfuerzos e investigaciones relacionadas con MINIX.
Se realizó una vez en 2016. MINIXCon2017 fue cancelada por falta de pláticas presentadas. [26] [27]
Ver también
- Comparación de los núcleos del sistema operativo
- Sistema de archivos MINIX
- Lista de mascotas informáticas
- Categoría: Mascotas informáticas
Referencias
- ↑ corbet (24 de octubre de 2005). "Minix 3 llega a la red" . Lwn.net . Consultado el 1 de mayo de 2014 .
- ^ "minix3.org" . minix3.org . Consultado el 16 de abril de 2017 .
- ^ "Introducción a Minix en Bochs en Mac OS" . Woodhull.com . Consultado el 1 de mayo de 2014 .
- ^ "OSNews.com" . OSNews.com . Consultado el 1 de mayo de 2014 .
- ^ "Instrucciones de instalación de Minix en VMWare" . Patrick.wagstrom.net. Archivado desde el original el 12 de noviembre de 2013 . Consultado el 1 de mayo de 2014 .
- ^ "Minix en Virtual PC: primer vistazo" . Woodhull.com . Consultado el 1 de mayo de 2014 .
- ^ "Minix 3 en caja virtual" . inopinion.org.
- ^ Alting, Ingmar. "Un puerto del SO MINIX a la plataforma PowerPC" (PDF) .
- ^ "Minix3" . Minix3 . Consultado el 1 de mayo de 2014 .
- ^ http://download.minix3.org/iso/snapshot/
- ^ "Intel ME: el camino del análisis estático" . blog.ptsecurity.com . Consultado el 28 de agosto de 2017 .
- ^ Corna, Nicola (28 de agosto de 2017). "me_cleaner: herramienta para la eliminación parcial de imágenes de firmware Intel ME / TXE" . Consultado el 28 de agosto de 2017 .
- ^ http://www.cs.vu.nl/~ast/intel/
- ^ Tanenbaum, Andy (25 de septiembre de 2006). "Introducción a MINIX 3" . OSnew . OSnews . Consultado el 4 de julio de 2008 .
De la sección Rebirth : "Varios estudios han demostrado que, en general, el software contiene entre 6 y 16 errores por 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 las fallas se deben a errores en los controladores de dispositivos. Obviamente, para hacer que los sistemas operativos sean confiables, algo debe hacerse para lidiar con los controladores de dispositivos con errores. La construcción de un sistema confiable a pesar de los inevitables errores en los controladores de dispositivos fue la fuerza motriz original detrás de MINIX 3. "
- ^ "Calendario de eventos de CSAIL" . Csail.mit.edu. Archivado desde el original el 4 de febrero de 2012 . Consultado el 1 de mayo de 2014 .
- ^ a b "Debate Tanenbaum-Torvalds, Parte II" . Cs.vu.nl. 2006-05-12 . Consultado el 1 de mayo de 2014 .
- ^ http://www.MINIX3.org/reliability.html Archivado el 1 de julio de 2006 en Wayback Machine.
- ^ "MinixReleases - Minix Wiki" . Wiki.minix3.org . Consultado el 1 de mayo de 2014 .
- ^ Rápido, Björn Patrick. "Programación en modo de usuario de asignación de programación individual Programación en MINIX 3" (PDF) . Minix3.org.
- ^ Versión de MINIX 3.3.0
- ^ "El sistema operativo MINIX 3" . minix3.org . Archivado desde el original el 22 de enero de 2012.
- ^ "Preguntas frecuentes - Minix Wiki" . Minix3.org. 2013-11-09 . Consultado el 1 de mayo de 2014 .
- ^ http://www.minix3.org/improvements.html Archivado el 17 de abril de 2006 en Wayback Machine.
- ^ "Lanzamientos MINIX" . wiki.minix3.org . Archivado desde el original el 18 de junio de 2012 . Consultado el 29 de febrero de 2012 .
- ^ "mascota [Wiki]" . wiki.minix3.org . Consultado el 20 de julio de 2017 .
- ^ Archivado el 10 de noviembre de 2017 en Wayback Machine.
- ^ "Minix3" . www.minix3.org . Consultado el 11 de noviembre de 2017 .
Otras lecturas
- Tanenbaum, Andrew S ; Woodhull, Albert S. (14 de enero de 2006). Sistemas operativos: diseño e implementación (3ª ed.). Prentice Hall . ISBN 0-13-142938-8.
- Construyendo un sistema operativo confiable: tolerancia a fallas en MINIX 3 por Jorrit N. Herder (PDF)
- Reorganización de Unix para la confiabilidad por Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg y Andrew S. Tanenbaum (PDF)
- Programación de sistema modular en MINIX 3 por Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg y Andrew S Tanenbaum (PDF)
- JN Herder et al., Programación de sistemas modulares en MINIX 3 ; Inicio de sesión, abril de 2006 (PDF)
- Pablo A Pessolani. MINIX4RT: un sistema operativo en tiempo real basado en MINIX
- Creación de herramientas de medición del rendimiento para el sistema operativo MINIX 3 , por Rogier Meurs (PDF)
- Diseño e implementación del sistema de archivos virtual MINIX (PDF)
- Manual de referencia para MINIX 3 Kernel API (PDF)
- Hacia un verdadero sistema operativo de microkernel (PDF)
- Construcción de un sistema operativo altamente confiable (PDF)
- Minix 3 y la experiencia del microkernel: Smart Kernel de Rüdiger Weis (PDF)
- Actualización en vivo segura y automática de Cristiano Giuffrida (PDF)
enlaces externos
- Página web oficial
- Wiki
- Código fuente
- MINIX 3: un sistema operativo modular, compatible con POSIX y autorreparable en YouTube
- minix3.ru (en ruso)
- comp.os.minix - foro oficial (desde 1987)
- Descripción de Minix 3 por Andy Tanenbaum
- MINIX: ¿qué es y por qué sigue siendo relevante? Una entrevista con Andy Tanenbaum
- Documentación del servicio de red Minix
- ¿Podemos hacer que los sistemas operativos sean confiables y seguros?
- Instalación de Minix3 en YouTube
- Una reimplementación de NetBSD basada en un microkernel
- MINIX 3 en ARM por Kees Jongenburger
- Lecciones aprendidas durante 30 años de MINIX por Andrew S. Tanenbaum