Sistema Operativo Libre de Código abierto, muy confiable, abierto y seguro
Minix 3 se liberó públicamente el 24 de Octubre del 2005 por *Andrew Tanenbaum*, durante su discurso en la Conferencia de Principios de Sistemas Operativos Symposium ACM. A pesar de que todavía sirve como un ejemplo para la nueva edición del libro de texto de Tanenbaun y Woodhull, se ha rediseñado integralmente para ser utilizado *como un sistema serio para computadoras de recursos limitados y computadores embebidos y para aplicaciones que requieren alta confiabilidad*.
Uno de los principales objetivos de MINIX-3 es la confiabilidad. Discutiremos a continuación algunos de los principios más importantes que mejoran la fiabilidad de MINIX-3.
Los sistemas operativos monolíticos como Linux y FreeBSD, y los híbridos como Windows, tienen millones de líneas de código en el kernel. Al contrario de ellos MINIX-3 tiene sólo alrededor de 6.000 líneas de código en el núcleo, lo que permite encontrar y resolver problemas en el código en forma más fácil.
En los kernel monolíticos, los controladores de dispositivos se encuentran en el propio kernel. Esto significa que cuando se instala un nuevo dispositivo o periférico puede haber código no confiable que se *inserta* en el núcleo. Una única línea de código mal escrita en un driver de dispositivo puede comprometer al sistema.
En MINIX-3 cada controlador de dispositivo es un proceso independiente en modo usuario. Los drivers no pueden ejecutar instrucciones privilegiadas, cambiar las tablas de paginamiento, realizar entradas y salidas arbitrarias de I/O o escribir directamente en la memoria real. Tienen que hacer llamadas o solicitudes a kernel para realizar estas acciones y el kernel chequea cada llamada para autorizarlo.
En los kernel monolíticos, un drivers puede escribir en cualquier parte de la memoria y por lo tanto puede escribir cualquier basura accidentalmente en los programas de usuario.
En MINIX-3 cuando un usuario espera datos desde, por ejemplo, el Sistema de Archivos, se construye un descriptor que indica quien tiene acceso y para que direcciones. A continución pasa un indice de este descriptor para el Sistema de Archivos, el cual puede pasar a un driver. El Sistema de Archivos o el Drivers le solicitan al núcleo escribir mediante el descriptor, por lo que es imposible para ellos escribir fuera de la memoria intermedia.
Referenciar un puntero errado dentro de un driver, bloqueará el proceso del drivers, pero no tendrá ningún efecto sobre el sistema operativo. El servidor de *Reencarnación* reiniciará automáticamente el driver bloqueado. Para algunos controladores (por ejemplo discos o red), la recuperación es transparente para los procesos de usuario. Para otros (por ejemplo impresoras o sonido), el usuario lo puede notar. En los kernels monolíticos, referenciar a un puntero errado en un driver conduce normalmente a un fallo de sistema.
Si un drivers se mete en un *loops infinito*, el controlador de procesos (scheduler) bajará su prioridad gradualmente hasta que se vuelva inactivo. Eventualmente el servidor de reencarnación detectará que el driver-loop no responde a las solicitudes de estado, por lo que matará al proceso y lo reiniciará. En un kernel monolítico, un driver en loop puede llegar a bloquear el sistema.
MINIX-3 utiliza mensajes de largo fijo para las comunicaciones internas, lo que elimina los desbordamientos de memoria y los problemas de administración de memoria. Además, muchos exploits trabajan sobre los *overrunning* de los buffers para engañar al programa al regresar de una llamada de función usando una dirección de retorno sobre escrita en el stack que retorna un puntero que ataca al controlador de memoria, normalmente sobre escribiendo el mismo buffer.
En MINIX-3 este ataque es mitigado porque el espacio de instrucciones y datos son divididos y sólo el código instrucciones de sólo lectura pueden ser ejecutados, técnica conocida comunmente como Prevención de Ejecución de Datos. Sin embargo, los ataques que se basan en la lejitima ejecución en memoria en forma malintensionada (return-to-libc, programación return-oriented), no son resueltas en esta mitigación.
Los controladores de dispositivos obtienen los servicios del núcleo (como copiar datos al espacio de direcciones de los usuarios) al hacer llamadas al kernel. El kernel de MINIX-3 tiene un mapa de bits para cada controlador especificando que llamadas tiene autorizadas a realizar. En un kernel monolítico, cualquier diver puede llamar a cualquier función del kernel, este autorizado a no.
El kernel también mantiene una tabla de los puertos de I/O que pueden acceder cada driver. Como resultado, un driver sólo puede usar sus propios puertos de I/O. En los núcleos monolíticos, un driver puede tener acceso a los puertos de I/O que pertenecen a otros dispositivos.
No todos los Drivers y el Server deben comunicarse con otro Drivers o Servidor. Por consecuancia se hace un mapa de bits por proceso que determina que proceso puede comunicarse con cual otro.
Un proceso especial, llamado servidor de encarnación, hace un ping periódicamente a cada driver de dispositivo. Si el Driver muere o no responde correctamente a los pings, el servidor de reencarnación reemplaza automáticamente al Drivers con una nueva copia. La detección y sustitución de los Drivers que no funcionan es automática y no se requiere ninguna intervención por parte del usuario. Esta característica no funciona para los controladores de discos en la actualidad pero en la próxima versión del sistema operativo será capaz de recuperar incluso los controladores de disco, que serán compartidos en la memoria RAM. La recuperación no afecta a los procesos que se encuentran en ejecución.
Cuando se produce una interrupción, esta se convierte a un low-level para enviar una notificación al Driver apropiado. Si el Drivers está esperando por un mensaje, este obtiene la interrupción en forma inmediata; de lo contrario, se hace la notificación la próxima vez que lo hace un RECEIVE que hace llegar el mensaje. Este esquema elimina las interrupciones anidadas y hace más fácil la programación del Drivers.
Se describe el proceso de instalación de MINIX-3 en una Virtualbox.
Descargue la última ISO de MINIX-3, en este documento hemos utilizado la versión minix_R3.3.0-588a35b.iso
Version | Medio | Imagen | Torrent | md5sum |
:——– | :—–: | :——: | :——-: | :——- |
3.3.3 (stable release) | CD-ROM | 288MB | Torrent | 3234ffcebfb228069cf3def41c95dec |
3.2.1 (previous | CD-ROM | 256MB | Torrent | 4c91ba7822cfa441d27755a7e7c4711d |
Primero que todo usted necesita instalar [Virtualbox](https://www.virtualbox.org), los binarios se pueden descargar de su página web. Sis está ejecutando alguna distribución de Linux, puede instalar VirtualBox a traves de su gestor de paquetes.
Antes de instalar MINIX-3 tendrá que crear una nueva máquina virtual. La configuración de la VM especifica los parámetros de la máquina virtual, por ejmplo, la cantidad de memoria que le asignará a la VM, debe definir el tamaño del disco virtual que le asignará, etc. Para las instrucciones detalladas, vea esta [Guía](http://wiki.minix3.org/doku.php?id=usersguide:hardwarerequirements).
En la pantalla principal de VirtualBox, presione el botón de Nueva.
Suponiendo que usted ha descargado y descomprimido una imagen ISO de MINIX-3 desde [download](http://www.minix3.org/download), usted puede montar el archivo ISO.
Los siguientes pasos corresponden a los pasos que aparecen en la pantalla de instalación de MINIX-3.
Cuando aparece el *prompt* de login, ingrese como *root*. Presione *\<enter\>* cuando el propmt cuando le solicite la password.
Para iniciar la instalación de MINIX en el disco virtual escriba *\<setup\>*.
Esto iniciará un script de instalación del sistema en su disco duro virtual. Si en el proceso su pantalla se pone en blanco (sin imagen), presione las teclas *\<ctrl + F3\>* esto sólo debería pasar en equipos antiguos.
Las aplicaciones de *Guest* de VirtualBox no se encuentran disponibles para MINIX-3. Por lo tanto MINIX-3 no puede adivinar correctamente la resolución de pantalla. La resolución de pantalla se tiene que configurar manualmenteen el archivo *xorg.conf*
Asegúrese que no está ejecutando X.org, para configurar ingrese como *root* y ejecute el siguiente comando:
# Xorg -configure
Este comando debe crear un archivo *xorg.conf.new* en el home de /root.
En la sección *Screen* del archivo *xorg.conf.new*, asegúrese de retirar toda la subsección *Display*, excepto lo que contiene *Depth: 16*.
Añada la resolución de pantalla. La posible resolución de pantalla puede ver encontrada en el archivo */var/log/Xorg.0.log*. Busque los Modes: que contengan *BitsPerPixel:16*, esto es importante.
Ejemplo:
Mode: 117 (1024x768) [....] XResolution: 1024 YResolution: 768 [....] BitsPerPixel: 16
Estas resoluciones pueden set añadidas al archivo *xorg.conf.local*, en el ejemplo anterior usamos 1024×768. Añada la resolución correcta de su pantalla en la sección *Display*.
Una vez que terminada la configuración del archivo *xorg.conf.new* debe mover el archivo al siguiente directorio:
# mv xorg.conf.new /usr/pkg/X11R6/lib/X11/xorg.conf
Para probar la nueva configuración debe arrancar X.org:
# startx
Y debería tener un ambiente gráfico con la reolución que ha definido y con la profundidad de colores que ha indicado en el archivo de configuración.
VirtualBox tiene ocho adaptadores de red que se pueden configurar por separado para operar en uno de los siguientes seis modos:
Es posible navegar por internet, descargar archivos, ver correo electrónico en MINIX-3 en modo NAT. En este modo por defecto (NAT), el sistema operativo invitado, no puede acceder a la máquina anfitriona o a otros equipos de la misma red y viceversa. Sin embargo, tal como un Router físico, VirtualBox puede hacer que los servicios disponibles puedan ser usados a través del *forwarding* de puertos. Esto significa que VirtualBox escucha a ciertos puertos en el anfitrión y redirecciona los paquetes que llegan a ese puerto y los envía al *huésped*, al mismo puerto o a un puerto diferente.
Por ejemplo para enviar el tráfico SSH desde el anfitrión al huésped por el puerto 2222:
VBoxManage modifyvm "VM_name" --natpf1 "guestssh, tcp,,2222,,22"
El “VM_name” es el nombre de la Máquina Virtual en la pantalla de administración del VirtualBox y “guestssh” es un nombre descriptivo y será generado automáticamente si se omite. Conectando la máquina huésped con el siguiente comando en el anfitrión:
ssh -P 2222 localhost
El sistema operativo invitado está disponible para la máquina anfitriona y otras máquinas de la red a través del puerto 2222 a través de la dirección IP del anfitrión (siempre que el firewall lo permita). Esto es útil para desarrollo remoto y navegación con sistema Remoto con explorador de Eclipse.