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

13

Preguntador / comentarista por primera vez, lector desde hace mucho tiempo.

Como alguien que actualmente está pensando mucho y amp; escribir sobre medidas que podrían mejorar de manera fundamental la seguridad informática (es decir, involucrando no solo el tipo de pasos evolutivos, bastante modestos en los que se centran la mayoría de los fabricantes de tecnología en este momento, sino que los cambios de "gran salto" podrían romper la compatibilidad hacia atrás, pero los sistemas podrían em> mucho más seguro). Me gusta mucho la idea de utilizar un aislamiento general robusto del proceso para intentar evitar que los programas en modo de usuario (o, de todos modos, lo que hoy llamamos programas en "modo de usuario") puedan hacer cosas desagradables como tratar de leer / robar datos utilizados por otros programas en modo usuario o golpear el sistema operativo con ataques de escalamiento de privilegios.

Ahora, ciertamente hay compañías / organizaciones que han intentado o están intentando implementar esquemas de aislamiento de privilegios sólidos en el software. Por ejemplo, el SO de Singularity de desarrollo de Microsoft que puso casi todo en "procesos aislados sellados" que solo podían comunicarse entre sí y con el SO mediante "contratos" de paso de mensajes restrictivos. (Ciertamente, hay otros, incluidos algunos que están en uso con los gobiernos para los escenarios de alta seguridad militar / inteligencia). Sin embargo, supongo que soy una persona que es reacia a confiar tremendamente en las defensas de seguridad que no están arraigadas. Al final del día, en algún tipo de aplicación directa de hardware. Lo que me lleva a mis dos preguntas (muy relacionadas):

En primer lugar, ¿hay microprocesadores no gubernamentales, producidos comercialmente hoy en día, destinados a la computación multipropósito? ¿No hay chips de tarjetas inteligentes o algo así, que utilicen conjuntos de instrucciones / arquitecturas específicamente diseñadas para imponer un aislamiento / separación de procesos sólido? (De tal manera que ni siquiera un ataque que explote una falla profunda en el kernel del sistema operativo que se ejecuta en el dispositivo sería suficiente para permitir que los códigos maliciosos en un proceso se salgan del aislamiento).

Segundo, ¿qué tipo de cambios necesitarías hacer al conjunto de instrucciones x86-64 & ¿Arquitectura de chip correspondiente para que sea capaz de proporcionar soporte forzado por hardware a un aislamiento / separación de procesos individuales fuerte del SO?

(FYI, sé que Intel ha agregado algunas capacidades de seguridad propietarias a algunos de sus chips en los últimos 5-10 años, con Skylake con SGX este año se supone que traerá algunas capacidades para aislar un programa dado que tiene alto necesidades de seguridad del resto del sistema. Pero mucho más grandes, se necesitarían pasos adicionales para lograr el aislamiento forzado por hardware de, digamos, como mínimo, todos los procesos que hoy se ejecutan en modo de usuario. ¿O me equivoco al respecto?)

    
pregunta halfinformed 09.09.2015 - 23:28
fuente

2 respuestas

14

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.

    
respondido por el Thomas Pornin 10.09.2015 - 00:09
fuente
1

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.

    
respondido por el Master 25.11.2016 - 09:01
fuente

Lea otras preguntas en las etiquetas