¿Hay alguna arquitectura actualmente que use aislamiento de procesos forzado por hardware? ¿Qué se necesitaría para agregar eso a x86?

En realidad, casi todas las CPU del mercado, excepto las muy pequeñas destinadas a dispositivos integrados de baja potencia, ofrecen "aislamiento forzado por hardware". Esto se denomina MMU . Sintéticamente, la MMU divide el espacio de direcciones en páginas individuales (generalmente de 4 u 8 kB cada una; depende de la arquitectura y la versión de la CPU), y cada vez que algún fragmento de código accede a una página, la MMU impone derechos de acceso y también asigna el acceso. a una dirección física (o no, así es como funciona la "memoria virtual"). En cualquier momento, la CPU informa a la MMU si el código actual es "código de usuario" o "código del kernel", y la MMU utiliza esa información para saber si se otorgará el acceso o no.

Los derechos de acceso y la asignación a las direcciones físicas de cada página se configuran en tablas especiales en la memoria, que el kernel muestra a la MMU (básicamente escribiendo la dirección de inicio en la RAM física de la tabla principal en un registro dedicado). Al cambiar la configuración de la MMU, el kernel implementa la noción de proceso : cada proceso tiene su propio espacio de direcciones, y cuando el kernel decide que la CPU se otorgará a un proceso, lo hace al hacer el Configuración de MMU para ese proceso la configuración activa.

Esto se trata de una aplicación forzada por hardware que estas cosas pueden obtener. Si deseaba una aplicación de aislamiento de software-solo , entonces tendría que mirar cosas como Java o C # / .NET: la tipificación fuerte, la verificación de los límites de la matriz y la recolección de basura permiten la cohabitación de distintas partes del código Con aislamiento y sin la ayuda de una MMU.

El aislamiento de procesos basado en MMU funciona bien en la práctica: los procesos no pueden alterar ni ver las páginas de otros procesos. Los últimos sistemas operativos principales en los que esto no se realizó correctamente fueron la familia Windows-95 (hasta e incluyendo la infame Windows Millenium Edition, en 2001).

El problema comienza cuando comienza a comprender que el aislamiento completo no sirve para nada: los procesos de la aplicación deben, en algún momento, poder interactuar con el hardware, guardar archivos o enviar datos a través de la red o mostrar imágenes. Por lo tanto, debe haber algunas puertas de enlace específicas que permitan que algunos datos entren y salgan del espacio de direcciones aislado de cada proceso, bajo el control estricto de un sistema de arbitraje que mantiene la coherencia y la asignación de recursos de hardware para procesar; ese sistema de arbitraje es exactamente lo que se conoce como "sistema operativo". Las "puertas de enlace" para escapar del aislamiento a menudo se denominan llamadas al sistema .

En este momento, el sistema operativo es software y tiene errores, porque cada pieza importante de software tiene errores. Algunos de estos permiten que procesos maliciosamente escritos impacten otros procesos de manera incorrecta; Esto se conoce como "agujeros de seguridad". Sin embargo, hacer un "sistema operativo totalmente de hardware" no resolvería nada; de hecho, probablemente empeoraría las cosas. El hardware tiene errores también; y la fuente de errores es que lo que el desarrollador está tratando de hacer es complejo. Hacerlo en hardware solo hace que la corrección de errores sea mucho más difícil, por lo que no mejora la situación de seguridad en absoluto.

Por lo tanto, para hacer un mejor aislamiento entre los procesos, la solución no es lanzar más hardware al problema. Ya hay suficiente de las cosas (y tal vez demasiado). Lo que se necesita es una reducción de la complejidad , que en realidad es una poda y un rediseño exhaustivos de la lista de llamadas al sistema. ¡Un kernel básico de Linux ofrece más de 300 llamadas de sistemas diferentes! Esto hace que una gran cantidad de trabajo al tratar de evitar agujeros de seguridad. Desafortunadamente, eliminar las llamadas al sistema rompe la compatibilidad con el código existente.

Primero, la implementación actual del "aislamiento forzado por hardware" parece insuficiente y débil. Aquí hay algunas preguntas "desagradables":

1. ¿Para qué el proceso que se ejecuta en modo "privilegiado" tiene acceso a los datos de todos los demás procesos?
2. ¿Deben ejecutarse los controladores de dispositivo en modo "privilegiado" o en modo "usuario"? Ambas soluciones causan problemas graves: los controladores que se ejecutan en modo "privilegiado" tienen demasiado acceso a datos confidenciales. Los controladores que se ejecutan en modo "usuario" deben acceder a los dispositivos, por lo tanto, el acceso al dispositivo debe otorgarse a las aplicaciones.
3. ¿Confiamos realmente en todos los proveedores de controladores de dispositivos?
4. Todos los sistemas operativos modernos se originan a partir de los tiempos en que lo que llamamos "buenas prácticas de programación" eran claramente desconocidos. Uno puede verificar el código de cualquier sistema operativo de código abierto y encontrar un montón de (lo siento) lío allí. ¿Creemos que los sistemas operativos comerciales son mucho mejores, simplemente porque no podemos ver su fuente?
5. Cualquier SO moderno es un SW realmente complejo. La forma común de mejorar la confiabilidad de SW complejos es su estructuración. Esta estructuración debe estar respaldada por algunos "límites" forzados entre varios módulos. No hay medios para apoyar / imponer dicho aislamiento en la programación del sistema operativo. Por lo tanto, solo confiamos en las buenas intenciones de las personas que diseñan, admiten y codifican los sistemas operativos.

Esta lista puede continuar.

Recientemente he buscado diseños de CPU que ayuden a resolver estos problemas. No se encontraron tales diseños.