Sistema operativo extremadamente confiable

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 19 de junio de 2013; las comprobaciones requieren 7 ediciones .

Extremely Reliable Operating System (EROS) es un sistema operativo basado en mandatos diseñado para cumplir con los requisitos de seguridad y confiabilidad de los sistemas activos . Los usuarios de sistemas activos pueden ingresar y ejecutar código arbitrario en cualquier momento , incluido código erróneo o incluso malicioso . Los sistemas activos son plataformas compartidas que deben admitir simultáneamente usuarios potencialmente competidores en la misma máquina al mismo tiempo.

Cómo funciona

Debido a que los sistemas activos ejecutan código proporcionado por el usuario, no puede confiar demasiado en la protección perimetral del sistema para evitar las consecuencias del código malicioso . En el caso de la ejecución de dicho código, EROS proporciona garantías tanto de seguridad como de funcionamiento del sistema. Las aplicaciones que ejecutan código malicioso (como virus ) no pueden dañar a otros usuarios ni al sistema en su totalidad, y no pueden usar los permisos otorgados a un usuario para dañar otras partes del entorno del usuario .

Historia del proyecto

El proyecto EROS comenzó como una implementación de referencia de KeyKOS , un sistema operativo creado por Norm Hardy y colegas para IBM System/370 . La principal contribución de EROS es probar formalmente algunas de las propiedades básicas de seguridad de una arquitectura , diseñando la implementación de características de rendimiento específicas. Estas características de protección y desempeño se lograron de dos maneras.

Primero, al crear la arquitectura básica del sistema , los desarrolladores se adhirieron a principios estrictos. En el caso de que la posibilidad prevista del sistema contradijera el principio de protección, se abandonó de inmediato. El resultado es una arquitectura pequeña, internamente consistente, cuyo comportamiento está bien definido y que conduce a una implementación completa y robusta. En segundo lugar, los arquitectos principales del sistema solían diseñar procesadores. Esto nos permitió evitar cierto tipo de abstracción, que tiende a distinguir los sistemas operativos modernos, y diseñar el sistema para que corresponda directamente a las funciones que ofrecen las implementaciones de hardware modernas; al convertir abstracciones, el rendimiento disminuye muy ligeramente.

Jeremy Salzer y Michael Schroeder desarrollaron muchos de los principios de diseño de EROS del proyecto Multics e integraron otros a partir de su experiencia en otros proyectos. La consistencia en el rendimiento y la arquitectura del sistema se logró únicamente al encontrar las mejores formas de implementar con precisión estos principios hasta en los matices, sin comprometer el rendimiento.

Los desarrolladores de EROS se adhirieron estrictamente a los principios de la arquitectura al diseñar EROS / KeyKOS ] por las siguientes tres razones. Debe estar seguro de que el sistema funciona y saber por qué funciona. Si para cada código del sistema es imposible decir cuál es el principio rector o la restricción obligatoria que garantiza la corrección, es muy difícil lograr este objetivo. La comunicación de este tipo también es necesaria para evaluar el rendimiento del sistema con un alto grado de certeza. Se supuso que una arquitectura clara contribuiría por sí misma a una implementación de alto rendimiento. Las pruebas de rendimiento realizadas confirmaron la exactitud de tales suposiciones.

Arquitectura central de EROS

La influencia más directa de los principios de diseño en EROS ha afectado la estructura y la implementación del kernel. En algunos casos, la estricta adherencia a los principios de diseño condujo a decisiones arquitectónicas inesperadas.

Reinicio seguro

En los sistemas seguros, debe asegurarse de que el sistema se encuentre en un estado constante y seguro después de un reinicio. La mayoría de los sistemas operativos tienen un conjunto inicial de procesos creados específicamente por el núcleo. Estos procesos realizan una verificación de consistencia, limitan sus poderes a los asumidos en modo estable y luego inician el resto de los programas en el sistema. En esta situación surgen dos problemas. La verificación de consistencia es heurística, lo que dificulta determinar su corrección. Por ejemplo, el comando fsck de Unix debe determinar qué archivos eliminar y cuáles conservar sin saber cómo se relacionan los archivos. Por lo tanto, el estado de los archivos y grupos de contraseñas puede ser incoherente entre sí. Los procesos iniciales obtienen su autoridad por medios que van más allá de los mecanismos habituales de otorgamiento o delegación de autoridad. Los desarrolladores deben crear medios específicos para demostrar que el sistema administra y reduce correctamente estos permisos. La complejidad de estas herramientas es comparable a la complejidad de los medios para garantizar la corrección del resto del sistema.

En EROS , ambos problemas se resuelven mediante el uso de un sistema para implementar puntos de control al ejecutar transacciones. Este sistema realiza periódicamente instantáneas asincrónicas racionales del estado de toda la máquina, verifica la consistencia de este estado y luego lo escribe como parte de una transacción de disco único. Dado que el sistema admite el mecanismo de transacciones en su conjunto, la situación de inconsistencia de todo el sistema es imposible. Al reiniciar, el sistema simplemente restaura la última transacción completada .

Kernel sin estado

EROS  es un núcleo sin estado: el estado de ejecución del sistema reside en la memoria reservada por el usuario. El rendimiento aceptable del kernel se logra almacenando en caché este estado. La arquitectura de almacenamiento en caché admite el mecanismo de punto de control y proporciona control de dependencias en el kernel. Para garantizar que la memoria reservada por el usuario siempre proporcione los valores correctos cuando se verifica, el kernel debe poder restaurar su estado a pedido. Estas dependencias ofrecen algún tipo de autocomprobación. El núcleo a veces puede comparar su estado en caché con el estado del usuario para detectar inconsistencias, evitando así que se escriba un estado incorrecto en el disco.

EROS no abre fragmentos de mapas de memoria ya que esto violaría el principio de estado de no conservación del núcleo. En cambio, EROS requiere que la aplicación reserve exactamente todos los fragmentos que componen la estructura de mapeo de memoria. La aplicación reserva explícitamente (generalmente con un controlador de errores a nivel de usuario) cada nodo y página en ese espacio de direcciones. El kernel crea las tablas de mapeo de hardware y memoria envolviendo esta estructura y almacenando en caché los resultados en las tablas de mapeo de hardware.

Véase también

Enlaces