Cómo el sistema operativo detecta las infracciones de acceso a la memoria

¿Cómo sabe un sistema operativo (preferiblemente Linux) que ha accedido a una ubicación de memoria que no tiene permitido?

¡Esta pregunta fue inspirada por esos malditos punteros! La forma en que lo veo es: todo en las computadoras se trata de un compromiso entre la velocidad, la seguridad, la integridad y esas cosas.

Soy muy consciente de los mapas de memoria en Linux, pero me parece un poco ridículo que el núcleo verifique si la ubicación a la que está intentando acceder reside en un rango válido CADA VEZ que realice un acceso. Parece que desperdiciaría tanto tiempo, que podría gastarse haciendo algo más productivo (¡pero posiblemente menos seguro sin verificar!). ¿O tal vez recuerda todos los accesos recientes y los verifica en cada tic del temporizador de hardware? (Pero eso suena inseguro y, una vez más, lento).

Me sorprendió que esta pregunta parece no tener respuesta en ningún lado. Es algo que siempre me he preguntado. Me hace pensar que hay una sección de hardware que hará esto en nombre del sistema operativo, en un nivel agradable y conveniente de abstracción. Pero aún así, posiblemente requeriría cargar los siguientes mapas de memoria de procesos en cada cambio de contexto, lo que nuevamente suena lento.

Entonces sí, de todos modos, voy a hablar un poco: ¿cómo detecta un sistema operativo una violación de memoria?

Gracias

(La siguiente respuesta supone un escritorio "moderno", un servidor o una plataforma integrada de gama alta (como teléfonos inteligentes y también sistemas cada vez más pequeños). Para los sistemas x86, moderno significa 386 y más. La siguiente respuesta también supone un SO "moderno", como casi cualquier Unix, o Windows desde 95.)

Esto no está sucediendo en el sistema operativo, está sucediendo en el procesador, específicamente en la MMU ( unidad de administración de memoria ) . La MMU admite el direccionamiento virtual, por lo que los bits que forman un puntero no indican directamente la ubicación física de los bits en la memoria.

En una MMU típica, cuando se desreferencia un puntero, la MMU divide los bits en dos grupos: los bits de orden superior constituyen el número de página y los bits de orden inferior constituyen la dirección dentro de la página. La mayoría de las máquinas de escritorio y servidor usan páginas de 4kB. La MMU busca el número de página virtual en una tabla llamada TLB (eso es lo que llamó los "mapas de memoria de proceso"). El TLB indica el número de la página física que corresponde a esta página virtual. La MMU luego obtiene los datos de la página física en la memoria.

Si el TLB no contiene una entrada para este número de página virtual en particular, la MMU notifica al procesador que se produjo un acceso no válido; Esto normalmente se llama una excepción.

Tenga en cuenta que no he mencionado el sistema operativo hasta ahora. Eso es porque toda esta operación es independiente del sistema operativo. El sistema operativo entra en juego porque configura las cosas de dos maneras:

• El sistema operativo es responsable de cambiar las tareas. Cuando lo hace, como sospechaba, guarda el TLB actual y lo reemplaza por el TLB guardado para la siguiente tarea programada. De esa manera, cada proceso tiene un TLB, por lo que la dirección 0x123456en el proceso X podría no apuntar al mismo lugar real en la RAM que esa misma dirección en el proceso Y, o simplemente podría no ser válida. Si un proceso intenta desreferenciar un puntero fuera de su espacio de direcciones, no alcanza el espacio de otro proceso, sino que no llega a ninguna parte .

• El sistema operativo decide qué sucede cuando se genera una excepción. Puede terminar el proceso para hacer un acceso no válido a la memoria (falla de segmentación, falla de protección general, ...). Esta es también la forma en que se implementa el intercambio: el controlador de excepciones puede decidir obtener algunos datos del espacio de intercambio, actualizar el TLB en consecuencia y realizar el acceso nuevamente.

Tenga en cuenta que la MMU proporciona seguridad porque el proceso no puede cambiar su propio TLB. Solo el núcleo del sistema operativo puede cambiar los TLB. Cómo funcionan los permisos de cambio de TLB está más allá del alcance de esta respuesta.

1) La unidad de gestión de memoria detecta los fallos de seguridad. Cuando solicita memoria, el sistema operativo le pide a la Unidad de administración de memoria que obtenga algo del hardware. Tiene que haber algo que haga un seguimiento de todos los grandes bloques de memoria que le proporciona el sistema operativo. El tipo de sistema operativo de las manos a la MMU. Como conoce toda la memoria que le proporcionó, también puede decirle cuándo intenta acceder a una ubicación de memoria que no obtuvo de las asignaciones. El sistema operativo tiene un evento específico para esto, memoria que no posee. Finalmente, el sistema operativo mata su aplicación, desencadenando un defecto o el equivalente en otros sistemas operativos.

No todos los sistemas operativos tienen esta protección. MacOS hasta 9 no tenía nada de esto, a pesar de que la MMU sí lo soportaba. Tampoco Win 3.1. Win95 tenía algo de protección, ya que hizo la transición entre no tener protección y luego agregar algo.

2) El sistema operativo no conoce más detalles que este. Si tiene un puntero perdido que accede a la memoria que nunca asignó, lo sabe. Si tiene uno que va a otra parte de su aplicación, no lo sabe, por supuesto. Te permite corromper esto. Aquí es donde obtienes pilas corruptas, con punteros extraviados de tu aplicación que sobrescriben otras partes de tu aplicación.

Entonces, sí, puedes atornillar tus propios datos. Si tiene un puntero perdido que sobrescribe su propia aplicación, ESPERA que golpee su pila, ya que eso probablemente causará otra violación cuando intente regresar de la pila, pero si golpea sus propios datos, nunca lo sabrá.

Puede intentar ser más estricto que 'sin protección', hay una herramienta llamada Electric Fence ( http://perens.com/FreeSoftware/ElectricFence/ ) que engañará a su MMU para que funcione un poco más y haga que detecte más fallas