¿Por qué tardó tanto tiempo en hacer cumplir los permisos de memoria?

5

Desde la página de Wikipedia en DEP .

  

DEP se introdujo en Linux en 2004 (kernel 2.6.8 [2]), en Windows en 2004 con Windows XP Service Pack 2, [3] mientras que Apple introdujo DEP cuando se trasladaron a x86 en 2006.

¿Por qué se tardó hasta 2004, cuando se lanzó DEP, para aplicar correctamente los indicadores de acceso a la página de memoria en el hardware? ¿Existen limitaciones en la arquitectura del hardware o software que lo dificultaron?

    
pregunta Ayrx 14.08.2012 - 15:13
fuente

2 respuestas

6

Es primordialmente una cuestión de análisis de costo-beneficio por parte del fabricante de hardware y una cuestión de análisis de riesgo en nombre de los proveedores de sistemas operativos.

La arquitectura x86 ha proporcionado derechos de acceso a la página de memoria desde el 80386, pero en ese momento tal aplicación de hardware habría sido costosa de implementar en el hardware y no se consideró necesaria. Las computadoras ya eran prohibitivamente caras para la mayoría de los usuarios, y la mayoría de las pequeñas empresas, por lo que los fabricantes de hardware no querían aumentar el costo por una característica que sus clientes no entenderían o les importaría.

A medida que avanzaba el tiempo, esta complacencia se hizo más evidente. La era de los desbordamientos de amortiguadores estaba sobre nosotros, y estaba empezando a afectar a las grandes empresas. Para el año 2003, la seguridad informática había demostrado ser un campo comercialmente rentable y los precios del hardware habían caído a niveles de productos básicos. AMD e Intel finalmente decidieron que la aplicación de hardware era una característica rentable, por lo que implementaron Never eXecute (NX) a principios de 2004. AMD lanzó el Athlon XP-M "Dublin" con soporte para NX, y el primer procesador de Intel que lo admitió fue el Pentium 4 Prescott (revisión E0). Sin embargo, en este punto, la cuota de mercado de los procesadores con NX era mínima.

La principal barrera para la implementación del software era que la Extensión de Dirección Física (PAE) tenía que habilitarse y admitirse antes de que NX estuviera disponible para su uso. Esto significó grandes cambios en la administración de la memoria central dentro de los kernels del sistema operativo.

Otra parte del problema en el lado del software fueron las aplicaciones mal escritas. Algunos códigos se basaban en la capacidad de ejecutar erróneamente datos que no se habían colocado en las páginas de memoria marcadas como ejecutables. Con el advenimiento de la aplicación de hardware de los indicadores de acceso a la memoria, estos programas lanzarán una infracción de acceso. Se necesitaba una cuidadosa consideración de los beneficios antes de continuar con los cambios. DEP como concepto, sin soporte de hardware, fue considerado como una característica potencial de Linux en una fecha anterior, pero fue rechazado debido a problemas de complejidad, cambios de ruptura y al hecho de que los mecanismos de aplicación de software podrían ser fácilmente ignorados.

Una vez que el soporte de hardware estaba disponible, los sistemas operativos tenían que ser modificados para usarlo. Esto no fue una tarea trivial. DEP marca ciertas estructuras importantes, como la pila y los montones, como no ejecutables. Esto requería que cada rutina de inicialización relacionada con la creación de subprocesos y procesos se modificara para admitir NX, así como ciertos cambios en la administración de la memoria (por ejemplo, asignaciones de montón). Finalmente, hubo que modificar algunos códigos de capa de abstracción de hardware para reconocer correctamente el indicador NX en los procesadores compatibles.

En general, esto sucedió sorprendentemente rápido. Una vez que la aplicación de NX por hardware estuvo disponible, tanto Windows XP como Linux lanzaron versiones compatibles con NX dentro de 8 meses.

    
respondido por el Polynomial 14.08.2012 - 15:29
fuente
1

Hay dos razones: (a) la seguridad no era una prioridad fuerte, y (b) las diferencias en las arquitecturas de 32 bits frente a las de 64 bits.

El bit NX solo se admite en arquitecturas de 64 bits. El bit NX proporciona permisos de ejecución a nivel de página, por lo que el sistema operativo puede marcar algunas páginas como no ejecutables. El bit NX es la forma estándar de hacer que algunas páginas no sean ejecutables y, por lo tanto, es la forma estándar y más limpia de implementar DEP. Sin embargo, las arquitecturas de 64 bits tardaron un poco en ganar popularidad, por lo que la implementación del soporte en el sistema operativo para DEP basado en NX bits solo se convirtió en un beneficio significativo para la seguridad una vez que muchas personas comenzaron a usar arquitecturas de 64 bits.

Por lo tanto, la implementación de DEP se ralentizó en parte por la lenta adopción de arquitecturas de 64 bits. (Si las plataformas Intel de 32 bits han admitido el bit NX, podríamos haber visto una implementación anterior de DEP, pero no fue así). DEP no se extendió hasta los chips Intel / AMD de 64 bits. se generalizó. Por lo tanto, es por eso que DEP tardó tanto en generalizarse.

Bien, ahora aquí es donde admito que lo anterior es una pequeña simplificación, aunque no demasiado. De hecho, hay una manera de implementar DEP en arquitecturas de 32 bits, pero es mucho más difícil y no encaja bien con la forma en que se construyen actualmente la mayoría de los sistemas operativos.

En las arquitecturas Intel de 32 bits, en realidad hay dos diferentes mecanismos de protección de memoria: protección a nivel de página y protección a nivel de segmento. La mayoría de los sistemas operativos se basan en el mecanismo de nivel de página (tablas de páginas y similares) para la protección de la memoria. El mecanismo de nivel de página es el más flexible, ya que cada página puede tener su propio nivel de protección (por ejemplo, solo lectura frente a lectura / escritura; accesible para el usuario frente al núcleo). Sin embargo, los procesadores Intel de 32 bits también admiten la protección de memoria basada en segmentos. Un segmento es una región consecutiva de la memoria, y puede tener algunos segmentos diferentes. Cada segmento puede recibir su propio acceso de protección. Debido a que la protección a nivel de página es más flexible, la mayoría de los sistemas operativos no usan la protección a nivel de segmento (tratan efectivamente la memoria como un segmento grande y dan vuelta a la segmentación).

Por alguna razón desconocida, en las arquitecturas de 32 bits, la protección a nivel de segmento permite marcar un segmento como no ejecutable, pero el mecanismo de protección a nivel de página no permite marcar una página como no ejecutable. (No sé por qué, probablemente solo sea un artefacto de la historia). Esto significa que es posible implementar DEP en una arquitectura de 32 bits, mediante el uso de las protecciones de nivel de segmento. Sin embargo, esto requiere todo tipo de contorsiones y cambios importantes en el sistema operativo. Hacerlo se vuelve un poco complicado y complicado, y también tiene algunas implicaciones de rendimiento. Por este motivo, muchos sistemas operativos eran reacios a implementar DEP en arquitecturas de 32 bits.

Por lo tanto, no es del todo exacto decir que DEP es imposible en arquitecturas de 32 bits y primero fue posible en arquitecturas de 64 bits, pero, para fines de ingeniería, es bastante cercano a la verdad.

    
respondido por el D.W. 14.08.2012 - 20:42
fuente

Lea otras preguntas en las etiquetas