Administración de memoria

La fragmentación comienza a aparecer cuando más procesos terminan su ejecución, y el sistema operativo libera la memoria asignada a cada uno de ellos. A medida que los procesos finalizan, aparecen regiones de memoria disponible, interrumpidas por regiones de memoria usada por los procesos que aún se encuentran activos.

Si la computadora no tiene hardware específico que permita que los procesos resuelvan sus direcciones en tiempo de ejecución, el sistema operativo no puede reasignar los bloques existentes, y aunque pudiera hacerlo, mover un proceso entero en memoria puede resultar una operación costosa en tiempo de procesamiento.

Al crear un nuevo proceso, el sistema operativo tiene tres estrategias según las cuales podría asignarle uno de los bloques disponibles:

Primer ajuste

El sistema toma el primer bloque con el tamaño suficiente para alojar el nuevo proceso. Este es el mecanismo más simple de implementar y el de más rápida ejecución. No obstante, esta estrategia puede causar el desperdicio de memoria, si el bloque no es exactamente del tamaño requerido.

Mejor ajuste

El sistema busca entre todos los bloques disponibles cuál es el que mejor se ajusta al tamaño requerido por el nuevo proceso. Esto implica la revisión completa de la lista de bloques, pero permite que los bloques remanentes, una vez que se ubicó al nuevo proceso, sean tan pequeños como sea posible (esto es, que haya de hecho un mejor ajuste).

Peor ajuste

El sistema busca cuál es el bloque más grande disponible, y se lo asigna al nuevo proceso. Empleando una estrucura de datos como un montículo, esta operación puede ser incluso más rápida que la de primer espacio. Con este mecanismo se busca que los bloques que queden después de otorgarlos a un proceso sean tan grandes como sea posible, de cierto modo balanceando su tamaño.

La fragmentación externa se produce cuando hay muchos bloques libres entre bloques asignados a procesos; la fragmentación interna se refiere a la cantidad de memoria dentro de un bloque que nunca se usará — Por ejemplo, si el sistema operativo maneja bloques de 512 bytes y un proceso requiere sólo 768 bytes para su ejecución, el sistema le entregará dos bloques (1024 bytes), con lo cual desperdicia 256 bytes. En el peor de los casos, con un bloque de bytes, un proceso podría solicitar bytes de memoria, desperdiciando por fragmentación interna bytes.

Según análisis estadísticos (Silberschatz, p.289), por cada N bloques asignados, se perderán del orden de 0.5N bloques por fragmentación interna y externa.

Un problema importante que va surgiendo como resultado de esta fragmentación es que el espacio total libre de memoria puede ser mucho mayor que lo que requiere un nuevo proceso, pero al estar fragmentada en muchos bloques, éste no encontrará una partición contigua donde ser cargado.

Si los procesos emplean resolución de direcciones en tiempo de ejecución, cuando el sistema operativo comience a detectar un alto índice de fragmentación, puede lanzar una operación de compresión o compactación. Esta operación consiste en mover los contenidos en memoria de los bloques asignados para que ocupen espacios contiguos, permitiendo unificar varios bloques libres contiguos en uno solo.

La compactación tiene un costo alto — Involucra mover prácticamente la totalidad de la memoria (probablemente más de una vez por bloque).

Siguiendo de cierto modo la lógica requerida por la compactación se encuentran los sistemas que utilizan intercambio (swap) entre la memoria primaria y secundaria. En estos sistemas, el sistema operativo puede comprometer más espacio de memoria del que tiene físicamente disponible. Cuando la memoria se acaba, el sistema suspende a un proceso (usualmente un proceso "bloqueado") y almacena una copia de su imagen en memoria en almacenamiento secundario para luego poder restaurarlo.

Hay algunas restricciones a observar previo a suspender un proceso. Por ejemplo, se debe considerar si el proceso tiene pendiente alguna operación de entrada/salida, en la cual el resultado se deberá copiar en su espacio de memoria. Si el proceso resultara suspendido (retirándolo de la memoria principal), el sistema operativo no tendría dónde continuar almacenando estos datos conforme llegaran. Una estrategia ante esta situación podría ser que todas las operaciones se realicen únicamente a buffers (regiones de memoria de almacenamiento temporal) en el espacio del sistema operativo, y éste las transfiera el contenido del buffer al espacio de memoria del proceso suspendido una vez que la operación finalice.

Esta técnica se popularizó en los sistemas de escritorio hacia fines de los 1980 y principios de los 1990, en que las computadoras personales tenían típicamente entre 1 y 8MB de memoria.

Se debe considerar que las unidades de disco son del orden de decenas de miles de veces más lentas que la memoria, por lo que este proceso resulta muy caro — Por ejemplo, si la imagen en memoria de un proceso es de 100MB, bastante conservador hoy en día, y la tasa de transferencia sostenida al disco de 50MB/s, intercambiar un proceso al disco toma dos segundos. Cargarlo de vuelta a memoria toma otros dos segundos — Y a esto debe sumarse el tiempo de posicionamiento de la cabeza de lectura/escritura, especialmente si el espacio a emplear no es secuencial y contiguo. Resulta obvio por qué esta técnica ha caído en desuso conforme aumenta el tamaño de los procesos.

En la sección MEM_swap, donde se presenta el concepto de intercambio, se explicó que intercambiar un proceso completo resultaba demasaido caro. Cuando se tiene de un espacio de memoria segmentado, y muy particularmente cuando se usan bibliotecas de carga dinámica, la sobrecarga es mucho menor:

En primer término, se puede hablar de la cantidad de información a intercambiar: En un sistema que sólo maneja regiones contiguas de memoria, intercambiar un proceso significa mover toda su información al disco. En un sistema con segmentación, puede enviarse a disco cada uno de los segmentos por separado, según el sistema operativo lo juzgue necesario. Podría sacar de memoria a alguno de los segmentos, eligiendo no necesariamente al que más estorbe (esto es, el más grande), sino el que más probablemente no esté siendo utilizado: Emplear el principio de localidad de referencia para intercambiar al segmento menos recientemente utilizado (LRU, Least Recently Used).

Además de esto, si se tiene un segmento de texto (sea el código programa base o alguna de las bibliotecas) y su acceso es de sólo lectura, una vez que éste fue copiado una vez al disco, ya no hace falta volver a hacerlo: Se tiene la certeza de que no será modificado por el proceso en ejecución, por lo que basta marcarlo como no presente en las tablas de segmentos en memoria para que cualquier acceso ocasione que el sistema operativo lo traiga de disco.

Por otro lado, si la biblioteca en cuestión reside en disco (antes de ser cargada) como una imagen directa de su representación en memoria, al sistema operativo le bastará identificar el archivo en cuestión al cargar el proceso; no hace falta siquiera cargarlo en la memoria principal y guardarlo al área de intercambio, puede quedar referido directamente al espacio en disco en que reside el archivo.

Claro está, el acceso a disco sigue siendo una fuerte penalización cada vez que un segmento tiene que ser cargado del disco (sea del sistema de archivos o del espacio de intercambio), pero este mecanismo reduce dicha penalización, haciendo más atractiva la flexibilidad del intercambio por segmentos.

La salida obvia a este dilema es el uso de un caché. Sin embargo, más que un caché genérico, la MMU utiliza un caché especializado en el tipo de información que maneja: El buffer de traducción adelantada o anticipada (Translation Lookaside Buffer, TLB). El TLB es una tabla asociativa (un hash) en memoria de alta velocidad, una suerte de registros residentes dentro de la MMU, donde las llaves son las páginas y los valores son los marcos correspondientes. De este modo, las búsquedas se efectúan en tiempo constante.

El TLB típicamente tiene entre 64 y 1024 entradas. Cuando el procesador efectúa un acceso a memoria, si la página solicitada está en el TLB, la MMU tiene la dirección física de inmediato.¹² En caso de no encontrarse la página en el TLB, la MMU lanza un fallo de página (page fault), con lo cual consulta de la memoria principal cuál es el marco correspondiente. Esta nueva entrada es agregada al TLB; por las propiedades de localidad de referencia que se presentaron anteriormente, la probabilidad de que las regiones más empleadas de la memoria durante un área específica de ejecución del programa sean cubiertas por relativamente pocas entradas del TLB son muy altas.

Como sea, dado que el TLB es limitado, es necesario explicitar un mecanismo que indique dónde guardar las nuevas entradas una vez que el TLB está lleno y se produce un fallo de página. Uno de los esquemas más comunes es emplear la entrada menos recientemente utilizada (LRU, Least Recently Used), nuevamente apelando a la localidad de referencia. Esto tiene como consecuencia necesaria que debe haber un mecanismo que contabilice los accesos dentro del TLB (lo cual agrega tanto latencia como costo). Otro mecanismo (con obvias desventajas) es el reemplazar una página al azar. Se explicará con mayor detalle más adelante algunos de los mecanismos más empleados para este fin, comparando sus puntos a favor y en contra.

Incluso empleando un TLB, el espacio empleado por las páginas sigue siendo demasiado grande. Si se considera un escenario más frecuente que el propuesto anteriormente: Empleando un procesador con espacio de direccionamiento de 32 bits, y un tamaño de página estándar (4KB, $2¹²), se tendría 1,048,576 () páginas. Si cada entrada de la página ocupa 40 bits¹³ (esto es, 5 bytes), cada proceso requeriría de 5MB (5 bytes por cada una de las páginas) sólamente para representar su mapeo de memoria. Esto, especialmente en procesos pequeños, resultaría más gravoso para el sistema que los beneficios obtenidos de la paginación.

Aprovechando que la mayor parte del espacio de direccionamiento de un proceso está típicamente vacío (la pila de llamadas y el heap), se puede subdividir el identificador de página en dos (o más) niveles, por ejemplo, separando una dirección de 32 bits en una tabla externa de 10 bits, una tabla interna de 10 bits, y el desplazamiento de 12 bits.

Este esquema funciona adecuadamente para computadoras con direccionamiento de hasta 32 bits. Sin embargo, se debe considerar que cada nivel de páginas conlleva un acceso adicional a memoria en caso de fallo de página — Emplear paginación jerárquica con un nivel externo y uno interno implica que un fallo de página triplica (y no duplica, como sería con un esquema de paginación directo) el tiempo de acceso a memoria. Para obtener una tabla de páginas manejable bajo los parámetros aquí descritos en un sistema de 64 bits, se puede septuplicar el tiempo de acceso (cinco accesos en cascada para fragmentos de 10 bits, y un tamaño de página de 14 bits, mas el acceso a la página destino).

Otra alternativa es el emplear funciones digestoras (hash functions)¹⁴ para mapear cada una de las páginas a un espacio muestral mucho más pequeño. Cada página es mapeada a una lista de correspondencias simples¹⁵.

Un esquema basado en funciones digestoras ofrece características muy deseables: El tamaño de la tabla de páginas puede variar según crece el uso de memoria de un proceso (aunque esto requiera recalcular la tabla con diferentes parámetros) y el número de accesos a memoria en espacios tan grandes como el de un procesador de 64 bits se mantiene mucho más tratable. Sin embargo, por la alta frecuencia de accesos a esta tabla, debe elegirse un algoritmo digestor muy ágil para evitar que el tiempo que tome calcular la posición en la tabla resulte significativo frente a las alternativas.

En los sistemas Unix, el mecanismo más frecuentemente utilizado para crear un nuevo proceso es el empleo de la llamada al sistema fork(). Cuando es invocado por un proceso, el sistema operativo crea a un nuevo proceso idéntico al que lo llamó, diferenciándose únicamente en el valor entregado por la llamada a fork(). Si ocurre algún error, el sistema entrega un número negativo (indicando la causa del error). En caso de ser exitoso, el proceso nuevo (o proceso hijo) recibe el valor 0, mientras que el proceso preexistente (o proceso padre) recibe el PID (número identificador de proceso) del hijo. Es frecuente encontrar el siguiente código:

/* (...) */
int pid;
/* (...) */
pid = fork();
if (pid == 0) {
  /* Soy el proceso hijo */
  /* (...) */
 } else if (pid < 0) {
  /* Ocurrió un error, no se creó un proceso hijo */
 } else {
  /* Soy el proceso padre */
  /* La variable 'pid' tiene el PID del proceso hijo */
  /* (...) */
 }

Este método es incluso utilizado normalmente para crear nuevos procesos, transfiriendo el ambiente (variables, por ejemplo, que incluyen cuál es la entrada y salida estándar de un proceso, esto es, a qué terminal están conectados, indispensable en un sistema multiusuario). Frecuentemente, la siguiente instrucción que ejecuta un proceso hijo es execve(), que carga a un nuevo programa sobre del actual y transfiere la ejecución a su primer instrucción.

Cuesta trabajo comprender el por qué de esta lógica si no es por el empleo de la memoria compartida: El costo de fork() en un sistema Unix es muy bajo, se limita a crear las estructuras necesarias en la memoria del núcleo. Tanto el proceso padre como el proceso hijo comparten todas sus páginas de memoria, como lo ilustra la figura MEM_{cowrecienhecho} — Sin embargo, siendo dos procesos independientes, no deben poder modificarse más que por los canales explícitos de comunicación entre procesos.

Esto ocurre así gracias a un mecanismo llamado Copiar al escribir (Copy on Write o CoW). Las páginas de memoria de ambos procesos son las mismas mientras sean sólo leídas. Sin embargo, si uno de los procesos modifica a cualquier dato en una de estas páginas, ésta se copia a un nuevo marco, y deja de ser una página compartida, como se puede ver en la figura MEM_{cowpaginamodificada}. El resto de las páginas seguirá siendo compartido. Esto se puede lograr marcando todas las páginas compartidas como sólo lectura, con lo cual cuando uno de los dos procesos intente modificar la información de alguna página se generará un fallo. El sistema operativo, al notar que esto ocurre sobre un espacio CoW, en vez de responder al fallo terminando al proceso, copiará sólo la página en la cual se encuentra la dirección de memoria que causó el fallo, y esta vez marcará la página como lectura y escritura.

Incluso cuando se ejecutan nuevos programas a través de execve(), es posible que una buena parte de la memoria se mantenga compartida, por ejemplo, al referirse a copias de bibliotecas de sistema.

El cálculo recién presentado, además, asume que el acomodo de las páginas en disco es óptimo. Sin embargo, si para llegar a una página hay que resolver la dirección que ocupa en un sistema de archivos (posiblemente navegar una estructura de directorio), y si el espacio asignado a la memoria virtual es compartido con los archivos en disco, el rendimiento sufrirá adicionalmente.

Una de las principales deficiencias estructurales en este sentido de los sistemas de la familia Windows es que el espacio de almacenamiento se asigna en el espacio libre del sistema de archivos. Esto lleva a que, conforme crece la fragmentación del disco, la memoria virtual quede esparcida por todo el disco duro. La generalidad de sistemas tipo Unix, en contraposición, reservan una partición de disco exclusivamente para paginación.

El algoritmo de más simple y de obvia implementación es, nuevamente, el FIFO: Al cargar una página en memoria, se toma nota de en qué momento fue cargada, y cuando llegue el momento de reemplazar una página vieja, se elige la que haya sido cargada hace más tiempo.

Partiendo de un estado inicial en que las tres páginas están vacías, necesariamente las tres primeras referencias a distintas páginas de memoria (7, 0, 1) causarán fallos de página. La siguiente (2) causará uno, pero la quinta referencia (0) puede ser satisfecha sin requerir una nueva transferencia.

La principal ventaja de este algoritmo es, como ya se ha mencionado, la simplicidad, tanto para programarlo como para comprenderlo. Su implementación puede ser tan simple como una lista ligada circular, cada elemento que va recibiendo se agrega en el último elemento de la lista, y se "empuja" el apuntador para convertirlo en la cabeza. Su desventaja, claro está, es que no toma en cuenta a la historia de las últimas solicitudes, por lo que puede causar un bajo rendimiento. Todas las páginas tienen la misma probabilidad de ser reemplazadas, sin importar su frecuencia de uso.

Con las condiciones aquí presentadas, un esquema FIFO causará 15 fallos de página en un total de 20 accesos requeridos.

El algoritmo FIFO es vulnerable a la anomalía de Belady. La figura MEM_{anomaliabelady} ilustra este fenómeno al pasar de 3 a 4 marcos.

La prevalencia de cadenas que desencadenan la anomalía de Belady fue uno de los factores principales que llevaron al diseño de nuevos algoritmos de reemplazo de páginas.

Un segundo algoritmo, de interés puramente teórico, fue propuesto, y es típicamente conocido como OPT o MIN. Bajo este algoritmo, el enunciado será elegir como página víctima a aquella página que no vaya a ser utilizada por un tiempo máximo (o nunca más).

Si bien este algoritmo está demostrado como óptimo o mínimo, se mantiene como curiosidad teórica porque requiere conocimiento a priori de las necesidades a futuro del sistema — Y si esto es impracticable ya en los algoritmos de despachadores, lo será mucho más con un recurso de reemplazo tan dinámico como la memoria.

Su principal utilidad reside en que ofrece una cota mínima: Calculando el número de fallos que se presentan al seguir OPT, es posible ver qué tan cercano resulta otro algoritmo respecto al caso óptimo. Para esta cadena de referencia, y con tres páginas, se tiene un total de nueve fallos.

Este esquema se ha revisado en diversos mecanismos relacionados con la administración de memoria. Busca acercarse a OPT prediciendo cuándo será la próxima vez en que se emplee cada una de las páginas que tiene en memoria basado en la historia reciente de su ejecución.

Cuando necesita elegir una página víctima, LRU elige la página que no ha sido empleada hace más tiempo.

Para la cadena de referencia, LRU genera 12 fallos, en el punto medio entre OPT y FIFO.

Una observación interesante puede ser que para una cadena y su cadena espejo (invertida) , el resultado de evaluar por LRU es igual al de evaluar por OPT, y viceversa.

La principal debilidad de LRU es que para su implementación requiere apoyo en hardware¹⁹ sensiblemente más complejo que FIFO. Una implementación podría ser agregar un contador a cada uno de los marcos, actualizarlo siempre al hacer una referenciar a dicha página, y elegir como víctima a la página con un menor conteo. Este mecanismo tiene la desventaja de que, en presencia de una gran cantidad de páginas, tiene que recorrerlas a todas para buscar a la más envejecida.

Otro mecanismo es emplear una lista doblemente ligada con dos métodos de acceso: Lista y stack. Cada vez que se haga referencia a una página, se mueve a la cabeza del stack, y cada vez que se busque a una página víctima, se selecciona a aquella que esté en el extremo inferior del stack. Este mecanismo hace un poco más cara la actualización (pueden requerirse hasta seis modificaciones), pero encuentra a la página víctima en tiempo constante.

Se ha demostrado que LRU y OPT están libres de la anomalía de Belady, dado que, para marcos, las páginas que estarían en memoria son un subconjunto estricto de las que estarían con marcos.

Estos dos algoritmos se basan en mantener un contador, como lo hace LRU, pero en vez de medir el tiempo, miden la cantidad de referencias que se han hecho a cada página.

MFU parte de la lógica que, si una página fue empleada muchas veces, probablemente vuelva a ser empleada muchas veces más; LFU parte de que una página que ha sido empleada pocas veces es probablemente una página recién cargada, y va a ser empleada en el futuro cercano.

Estos dos algoritmos son tan caros de implementar como LRU, y su rendimiento respecto a OPT no es tan cercana, por lo cual casi no son empleados.

Dada la complejidad que presenta la implementación de LRU en hardware, algunos sistemas implementan una aproximación a éste.

Bit de referencia

Esta es una aproximación bastante común. Consiste en que todas las entradas de la tabla de páginas tengan un bit adicional, al que llamaremos de referencia o de acceso. Al iniciar la ejecución, todos los bits de referencia están apagados (0). Cada vez que se referencia a un marco, su bit de referencia se enciende (esto en general lo realiza el hardware).

El sistema operativo invoca periódicamente a que se apaguen nuevamente todos los bits de referencia. En caso de presentarse un fallo de página, se elige por FIFO sobre el subconjunto de marcos que no hayan sido referenciados en el periodo actual (esto es, entre todos aquellos para los cuales el bit de referencia sea 0).

Columna de referencia

Una mejoría casi trivial sobre la anterior consiste en agregar varios bits de referencia, conformándose como una columna: En vez de descartar su valor cada vez que transcurre el periodo determinado, el valor de la columna de referencia es recorrido a la derecha, descartando el bit más bajo. Por ejemplo, con una implementación de 4 bits, un marco que no ha sido empleado en los últimos 4 periodos tendría el valor 0000, mientras que un marco que sí ha sido referenciado los últimos cuatro periodos tendría 1111. Un marco que fue empleado hace cuatro y tres periodos, pero desde entonces no, tendría el 0011.

Cuando el sistema tenga que elegir a una nueva página víctima, lo hará de entre el conjunto que tenga un número más bajo.

La parte de mantenimiento de este algoritmo es muy simple; recorrer una serie de bits es una operación muy sencilla. Seleccionar el número más pequeño requiere una pequeña búsqueda, pero sigue resultando mucho más sencillo que LRU.

Segunda oportunidad (o reloj)

El algoritmo de la segunda oportunidad trabaja también basado en un bit de referencia y un recorrido tipo FIFO. La diferencia en este caso es que, al igual que hay eventos que encienden a este bit (efectuar una referencia al marco), también hay eventos que lo apagan:

Se mantiene un apuntador a la próxima víctima, y cuando el sistema requiera efectuar un reemplazo, éste verificará si el marco al que apunta tiene el bit de referencia encendido o apagado. En caso de estar apagado, el marco es seleccionado como víctima, pero en caso de estar encendido (indicando que fue utilizado recientemente), se le da una segunda oportunidad: El bit de referencia se apaga, el apuntador de víctima potencial avanza una posición, y vuelve a intentarlo.

A este algoritmo se le llama también de reloj porque puede implementarse como una lista ligada circular, y el apuntador puede ser visto como una manecilla. La manecilla avanza sobre la lista de marcos buscando uno con el bit de referencia apagado, y apagando a todos a su paso.

En el peor caso, el algoritmo de segunda oportunidad degenera en FIFO.

Segunda oportunidad mejorada

El bit de referencia puede amplairse con un bit de modificación, dándonos las siguientes combinaciones, en orden de preferencia:

(0, 0)

No ha sido utilizado ni modificado recientemente. Candidato ideal para su reemplazo.

(0,1)

No ha sido utilizada recientemente, pero está modificada. No es tan buena opción, porque es necesario escribir la página a disco antes de reemplazarla, pero puede ser elegida.

(1,0)

El marco está limpio, pero fue empleado recientemente, por lo que probablemente se vuelva a requerir pronto.

(1,1)

Empleada recientemente y sucia — Sería necesario escribir la página a disco antes de reemplazar, y probablemente vuelva a ser requerida pronto. Hay que evitar reemplazarla.

La lógica para encontrar una página víctima es similar a la segunda oportunidad, pero busca reducir el costo de E/S. Esto puede requerir, sin embargo, dar hasta cuatro vueltas (por cada una de las listas) para elegir la página víctima.

Un mecanismo que se emplea con cada vez mayor frecuencia es que el sistema no espere a enfrentarse a la necesidad de reemplazar un marco, sino que proactivamente busque tener siempre espacio vacío en memoria. Para hacerlo, conforme la carga lo permite, el sistema operativo busca las páginas sucias más proclives a ser paginadas a disco y va actualizando el disco (y marcándolas nuevamente como limpias). De este modo, cuando tenga que traer una página nueva del disco, siempre habrá espacio donde ubicarla sin tener que esperar a que se transfiera una para liberarla.

Si un proceso tiene asignados muy pocos marcos, su rendimiento indudablemente se verá afectado. Hasta ahora se ha supuesto que cada instrucción puede causar un sólo fallo de página, pero la realidad es más compleja. Cada instrucción del procesador puede, dependiendo de la arquitectura, desencadenar varias solicitudes y potencialmente varios fallos de página.

Todas las arquitecturas proporcionan instrucciones de referencia directa a memoria (instrucciones que permiten especificar una dirección de memoria para leer o escribir) — Esto significa que todas requerirán que, para que un proceso funcione adecuadamente, tenga por lo menos dos marcos asignados: En caso de que se le permitiera solo uno, si la instrucción ubicada en 0x00A2C8 solicita la carga de 0x043F00, esta causaría dos fallos: El primero, cargar al marco la página 0x043, y el segundo, cargar nuevamente la página 0x00A, necesario para leer la siguiente instrucción a ejecutar del programa (0x00A2CC, asumiendo palabras de 32 bits).

Algunas arquitecturas, además, permiten referencias indirectas a memoria, esto es, la dirección de carga puede solicitar la dirección que está referenciada en 0x043F00. El procesador tendría que recuperar esta dirección, y podría encontrarse con que hace referencia a una dirección en otra página (por ejemplo, 0x010F80). Cada nivel de indirección que se permite aumenta en uno el número de páginas que se deben reservar como mínimo por proceso.

Algunas arquitecturas, particularmente las más antiguas,²¹, permiten que tanto los operandos de algunas instrucciones aritméticas como su resultado sean direcciones de memoria (y no operan estrictamente sobre los registros, como las arquitecturas RISC). En dichas arquitecturas, el mínimo debe también tener este factor en cuenta: Si en una sola instrucción es posible sumar dos direcciones de memoria y guardar el resultado en una adicional, el mínimo a reservar es de cuatro marcos: Uno para el flujo del programa, uno para el primer operando, uno para el segundo operando, y uno para el resultado.

Ahora, una vez establecido el número mínimo de marcos por proceso, ¿cómo determinar el nivel deseable?

Partiendo de que el rendimiento de un proceso será mejor entre menos fallos de paginación cause, se podría intentar otorgar a cada proceso el total de marcos que solicita — Pero esto tendría como resultado disminuir el grado de multiprogramación, y por tanto, reducir el uso efectivo total del procesador.

Otra alternativa es la asignación igualitaria: Se divide el total de espacio en memoria física entre todos los procesos en ejecución, en partes iguales. Esto es, volviendo a la computadora hipotética que se presentó al inicio de esta sección, si existen 4 procesos que requieren ser ejecutados, de los 194 marcos disponibles, el sistema asignará 48 marcos (192KB) a dos de los procesos y 49 (196KB) a los otros dos (es imposible asignar fracciones de marcos). De este modo, el espacio será compartido por igual.

La asignación igualitaria resulta ser un esquema deficiente para casi todas las distribuciones de procesos: Bajo este esquema, si es un gestor de bases de datos que puede estar empleando 2048KB (512 páginas) de memoria virtual (a pesar de que el sistema tiene sólo 1MB de memoria física) y es un lector de texto que está empleando un usuario, requiriendo apenas 112KB (28 páginas), con lo cual incluso dejaría algunos de sus marcos sin utilizar.

Un segundo esquema, que resuelve mejor esta situación, es la asignación proporcional: Dar a cada proceso una porción del espacio de memoria física proporcional a su uso de memoria virtual.

De tal suerte, si además de los procesos anteriores se tiene a empleando 560KB (140 páginas) y a con 320KB (80 páginas) de memoria virtual, el uso total de memoria virtual sería de páginas, esto es, el sistema tendría comprometido a través de la memoria virtual un sobreuso cercano a 4:1 sobre la memoria física²².

Cada proceso recibirá entonces , donde indica el espacio de memoria física que el proceso recibirá, la cantidad de memoria virtual que está empleando, y la cantidad total de marcos de memoria disponibles. De este modo, recibirá 130 marcos, 7, 35 y 20, proporcionalmente a su uso de memoria virtual.

Cabe apuntar que este mecanismo debe observar ciertos parámetros mínimos: Por un lado, si el mínimo de marcos definido para esta arquitectura es de 4, por más que entrara en ejecución un proceso de 32KB (8 páginas) o aumentara al doble el grado de multiprocesamiento, ningún proceso debe tener asignado menos del mínimo definido.

La asignación proporcional también debe cuidar no sobre-asignar recursos a un proceso obeso: es ya mucho más grande que todos los procesos del sistema. En caso de que esta creciera mucho más, por ejemplo, si multiplicara por 4 su uso de memoria virtual, esto llevaría a que se castigara desproporcionadamente a todos los demás procesos del sistema.

Por otro lado, este esquema ignora por completo las prioridades que hoy en día manejan todos los sistemas operativos; si se quisera considerar, podría incluirse como factor la prioridad, multiplicando junto con .

El esquema de asignación proporcional sufre, sin embargo, cuando cambia el nivel de multiprogramación — Esto es, cuando se inicia un nuevo proceso o finaliza un proceso en ejecución, deben recalcularse los espacios en memoria física asignados a cada uno de los procesos restantes. Si finaliza un proceso, el problema es menor, pues sólo se asignan los marcos y puede esperarse a que se vayan poblando por paginación sobre demanda, pero si inicia uno nuevo, es necesario reducir de golpe la asignación de todos los demás procesos hasta abrir suficiente espacio para que quepa.

Por último, el esquema de la asignación proporcional también tiende a desperdiciar recursos: Si bien hay procesos que mantienen un patrón estable de actividad a lo largo de su ejecución, muchos otros pueden tener periodos de mucho menor requisitos. Por ejemplo, un proceso servidor de documentos pasa la mayor parte de su tiempo simplemente esperando solicitudes, y podría reducirse a un uso mínimo de memoria física, sin embargo, al solicitársele un documento, se le deberían poder asignar más marcos (para trabajar en una ráfaga) hasta que termine con su tarea. En la sección MEM_{modconjuntoactivo} se retomará este tema.

Para atender a los problemas no resueltos que se describieron en la sección anterior, se puede discutir el ámbito en que operará el algoritmo de reemplazo de páginas.

Reemplazo local

Mantener tan estable como sea posible el cálculo hecho por el esquema de asignación empleado. Esto significa que cuando se presente un fallo de página, las páginas que serán consideradas para su intercambio serán únicamente aquellas pertenecientes al mismo proceso que el que causó el fallo.

Un proceso tiene asignado su espacio de memoria física, y se mantendrá estable mientras el sistema operativo no tome alguna decisión por cambiarlo.

Reemplazo global

Los algoritmos de asignación determinan el espacio asignado a los procesos al ser inicializados, e influyen a los algoritmos de reemplazo (por ejemplo, dando mayor peso para ser elegidas como páginas víctima a aquellas que pertenezcan a un proceso que excede de su asignación en memoria física).

Los algoritmos de reemplazo de páginas operan sobre el espacio completo de memoria, y la asignación física de cada proceso puede variar según el estado del sistema momento a momento.

Reemplazo global con prioridad

Es un esquema mixto, en el que un proceso puede sobrepasar su límite siempre que le robe espacio en memoria física exclusivamente a procesos de prioridad inferior a él. Esto es consistente con el comportamiento de los algoritmos planificadores, que siempre dan preferencia a un proceso de mayor prioridad por sobre de uno de prioridad más baja.

El reemplazo local es más rígido y no permite aprovechar para mejorar el rendimiento los periodos de inactividad de algunos de los procesos. En contraposición, los esquemas basados en reemplazo global pueden llevar a rendimiento inconsistente: Dado que la asignación de memoria física sale del control de cada proceso, puede que la misma sección de código presente tiempos de ejecución muy distintos si porciones importantes de su memoria fueron paginadas a disco.

Un pico en la cantidad de fallos de página no necesariamente significa que se va a presentar una situación de hiperpaginación — Muchas veces indica que el proceso cambió su atención de un conjunto de páginas a otro, o dicho de otro modo, que cambió el conjunto activo del proceso — Y resulta natural que, al cambiar el conjunto activo, el proceso accese de golpe una serie de páginas que no había referenciado en cierto tiempo.

El conjunto activo es, pues, la aproximación más clara a la localidad de referencia de un proceso dado: El conjunto de páginas sobre los que está iterando en un momento dado.

Idealmente, para evitar los problemas relacionados con la hiperpaginación, el sistema debe asignar a cada proceso suficientes páginas como para que mantenga en memoria física su conjunto activo — Y si no es posible hacerlo, el proceso es un buen candidato para ser suspendido. Sin embargo, detectar con suficiente claridad como para efectuar este diagnóstico cuál es el conjunto activo es una tarea muy compleja, que típicamente implica rastrear y verificar del orden de los últimos miles a decenas de miles de accesos a memoria.

Recordando lo mencionado en la sección MEM_{espacioenmemoria}, en que se presentó el espacio en memoria de un proceso, es conveniente profundizar un poco más acerca de cómo está estructurada la pila de llamadas (stack).

El stack es el mecanismo que brinda un sentido local a la representación del código estructurado. Está dividido en marcos de activación (sin relación con el concepto de marcos empleado al hablar de memoria virtual); durante el periodo en que es el marco activo (esto es, cuando no se ha transferido el control a ninguna otra función), está delimitado por dos valores, almacenados en registros:

Apuntador a la pila

(Stack pointer, SP) Apunta al final actual (dirección inferior) de la pila. En arquitecturas x86, emplea el registro ESP; cuando se pide al procesador que actúe sobre el stack (con las operaciones pushl o popl), lo hace sobre este registro

Apuntador del marco

(Frame pointer, FP, o Base local, LB) Apunta al inicio del marco actual, o lo que es lo mismo, al final del marco anterior. En arquitecturas x86, emplea el registro EBP.

A cada función a que va entrando la ejecución del proceso, se va creando un marco de activación en el stack, que incluye:

• Los argumentos recibidos por la función
• La dirección de retorno al código que la invocó
• Las variables locales creadas en la función

Con esto en mente, es posible analizar la traducción de una llamada a función en C a su equivalente en ensamblador, y en segundo término ver el marco del stack resultante:

void func(int a, int b, int c) {
   char buffer1[5];
   char buffer2[10];
}

void main() {
  func(1,2,3);
}

Y lo que el código resultante en ensamblador efectúa es:

1. El procesador empuja (pushl) los tres argumentos al stack (ESP). La notación empleada ($1, $2, $3) indica que el número indicado se expresa de forma literal. Cada uno de estos tres valores restará 4 bytes (el tamaño de un valor entero en x86-32) a ESP.
2. En ensamblador, los nombres asignados a las variables y funciones no significan nada. La llamada call no es lo que se entendería como una llamada a función en un lenguaje de alto nivel — Lo que hace el procesador es empujar al stack la dirección de la siguiente instrucción, y cargar a éste la dirección en el fuente donde está la etiqueta de la función (esto es, transferir la ejecución hacia allá).
3. Lo primero que hace la función al ser invocada es asegurarse de saber a dónde volver: empuja al stack el viejo apuntador al marco (EBP), y lo reemplaza (movl) por el actual. A esta ubicación se le llama SFP (Saved Frame Pointer, apuntador al marco grabado)
4. Por último, con subl, resta el espacio necesario para alojar las variables locales, buffer1 y buffer2. Notarán que, si bien éstas son de 5 y 10 bytes, está recorriendo 20 bytes — Esto porque, en la arquitectura x86-32, los accesos a memoria deben estar alineados a 32 bits.

; main
        pushl $3
        pushl $2
        pushl $1
        call func

func:
        pushl %ebp
        movl %esp,%ebp
        subl $20,%esp

La figura MEM_stackframe ilustra cómo queda la región inferior del stack (el espacio de trabajo de la función actual) una vez que tuvieron lugar estos cuatro pasos.

El lenguaje de programación C fue creado con el propósito de ser tan simple como sea posible, manteniéndose tan cerca del hardware como se pudiera, para que pudiera ser empleado como un lenguaje de programación para un sistema operativo portable. Y si bien en 1970 era visto como un lenguaje bastante de alto nivel, hoy en día es lo más bajo nivel en que programa la mayor parte de los desarrolladores del mundo.

C no tiene soporte nativo para cadenas de caracteres. El soporte es provisto a través de familias de funciones en la biblioteca estándar del lenguaje, que están siempre disponibles en cualquier implementación estándar de C. Las familias principales son strcat, strcpy, printf y gets. Estas funciones trabajan con cadenas que siguen la siguiente estructura:

• Son arreglos de 1 o más caracteres (char, 8 bits)
• Deben terminar con el byte de terminación NUL (\0)

El problema con estas funciones es que sólo algunas de las funciones derivadas implementan verificaciones de límites, y algunas son incluso capaces de crear cadenas ilegales (que no concluyan con el terminador \0).

El problema aparece cuando el programador no tiene el cuidado necesario al trabajar con datos de los cuales no tiene certeza. Esto se demuestra con el siguiente código vulnerable:

#include <stdio.h>
int main(int argc, char **argv) {
        char buffer[256];
        if(argc > 1) strcpy(buffer, argv[1]);
        printf("Escribiste %s\n", buffer);
        return 0;
}

El problema con este código reside en el strcpy(buffer, argv[1]) — Dado que el código es recibido del usuario, no se tiene la certeza de que el argumento que recibe el programa por línea de comandos (empleando argv[1]) quepa en el arreglo buffer[256]. Esto es, si se ejecuta el programa ejemplo con una cadena de 120 caracteres:

$ ./ejemplo1 `perl -e 'print "A" x 120'`
Escribiste: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA
$

La ejecución resulta exitosa. Sin embargo, si se ejecuta el programa con un parámetro demasiado largo para el arreglo:

$ ./ejemplo1 `perl -e 'print "A" x 500'`
Escribiste: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault
$

En el ejemplo recién presentado, parecería que el sistema atrapó al error exitosamente y detuvo la ejecución — Pero no lo hizo: El Segmentation fault no fue generado al sobreescribir el buffer ni al intentar procesarlo, sino después de terminar de hacerlo: Al llegar la ejecución del código al return 0. En este punto, el stack del código ejemplo luce como lo presenta la figura MEM_overflow500.

Para volver de una función a quien la invocó, incluso si dicha función es main(), lo que hace return es restaurar el viejo SFP y hacer que el apuntador a siguiente dirección salte a la dirección que tiene en RET. Sin embargo, como se observa en el esquema, RET fue sobreescrito por la dirección 0x41414141 (AAAA). Dado que esa dirección no forma parte del espacio del proceso actual, se lanza una excepción por violación de segmento, y el proceso es terminado.

Ahora, lo expuesto anteriormente implica que el código está demostrado vulnerable, pero se ha explotado aún. El siguiente paso es, conociendo el acomodo exacto de la memoria, sobreescribir únicamente lo necesario para altera del flujo del programa — Esto es, sobreescribir RET con una dirección válida. Para esto, es necesario conocer la longitud desde el inicio del buffer hasta donde terminan RET y SFP, en este caso particular, 264 bytes (256 del buffer mas 4 de RET mas 4 de SFP).

Citando al texto de Enrique Sánchez,

¿Por qué ocurre un desbordamiento de stack? Imagina un vaso y una botella de cerveza. ¿Qué ocurre si sirves la botella completa en el vaso? Se va a derramar. Imagina que tu variable es el vaso, y la entrada del usuario es la cerveza. Puede ocurrir que el usuario sirva tanto líquido como el que cabe en el vaso, pero puede también seguir sirviendo hasta que se derrame. La cerveza se derramaría en todas direcciones, pero la memoria no crece de esa manera, es sólo un arreglo bidimensional, y sólo crece en una dirección.

Ahora, ¿qué más pasa cuando desbordas a un contenedor? El líquido sobrante va a mojar la botana, los papeles, la mesa, etc. En el caso de los papeles, destruirá cualquier cosa que hubieras apuntado (como el teléfono que acabas de anotar de esa linda chica). Cuando tu variable se desborde, ¿qué va a sobrescribir? Al EBP, al EIP, y lo que les siga, dependiendo de la función, y si es la última función, las variables de ambiente. Puede que el programa aborte y tu shell resulte inutilizado a causa de las variables sobreescritas.

Hay dos técnicas principales: Saltar a un punto determinado del programa, y saltar hacia dentro del stack.

Un ejemplo de la primera técnica se muestra a continuación. Si el atacante está intentando burlar la siguiente validación simple de nombre de usuario y contraseña,

if (valid_user(usr, pass)) {
  /* (...) */
} else {
  printf("Error!\n");
  exit 1;
}

Y detecta que valid_user() es susceptible a un desbordamiento, le bastaría con incrementar en 4 la dirección de retorno. La conversión de este if a ensamblador es, primero, saltar hacia la etiqueta valid_user, y (empleando al valor que ésta regrese en %EBX) ir a la siguiente instrucción, o saltar a la etiqueta FAIL. Esto puede hacerse con la instrucción BNE $0, %EBX, FAIL (Branch if Not Equal, Saltar si no es igual, que recibe como argumentos dos valores a ser comparados, en este caso el registro %EBX y el número 0, y la etiqueta destino, FAIL). Cambiar la dirección destino significa burlar la verificación.

Por otro lado, el atacante podría usar la segunda técnica para lograr que el sistema haga algo más complejo — Por ejemplo, que ejecute código arbitrario que él proporcione. Para esto, el ataque más frecuente es saltar hacia adentro del stack.

Para hacerlo, si en vez de proporcionar simplemente una cadena suficientemente grande para sobrepasar el buffer se inyecta una cadena con código ejecutable válido, y sobreescribiera la dirección de retorno con la dirección de su código dentro del buffer, tendría 256 bytes de espacio para especificar código arbitrario. Este código típicamente se llama shellcode, pues se emplea para obtener un shell (un intérprete de comandos) que ejecuta con los privilegios del proceso explotado. Este escenario se ilustra en la figura MEM_overflowjump.

Claro está, el mundo no se queda quieto. Una vez que estos mecanismos de ataque se dieron a conocer, comenzó un fuerte trabajo para crear mecanismos de mitigación de daños.

La principal y más importante medida es crear una cultura de programadores conscientes y prácticas seguras. Esto cruza necesariamente el no emplear funciones que no hagan verificación de límites. La desventaja de esto es que hace falta cambiar al factor humano, lo cual resulta prácticamente imposible de lograr con suficiente profundidad²⁵. Muchos desarrolladores esgrimen argumentos en contra de estas prácticas, como la pérdida de rendimiento que estas funciones requieren, y muchos otros sencillamente nunca se dieron por enterados de la necesidad de programar correctamente.

Por esto, se han ido creando diversos mecanismos automatizados de protección ante los desbordamientos de buffer. Ninguno de estos mecanismos es perfecto, pero sí ayudan a reducir los riesgos ante los atacantes menos persistentes o habilidosos.

En secciones anteriores se describió la protección que puede imponer la MMU por regiones, evitando la modificación de código ejecutable.

En la arquitectura x86, dominante en el mercado de computadoras personales desde hace muchos años, esta característica existía en varios procesadores basados en el modelo de segmentación de memoria, pero desapareció al cambiarse el modelo predominante por uno de memoria plana paginada, y fue hasta alrededor del 2001 en que fue introducida de vuelta, bajo los nombres bit NX (Never eXecute, Nunca ejecutar) o bit XD (eXecute Disable, Deshabilitar ejecución), como una característica particular de las extensiones PAE.

Empleando este mecanismo, la MMU puede evitar la ejecución de código en el área de stack, lo cual anula la posibilidad de saltar al stack. Esta protección desafortunadamente no es muy efectiva: Una vez que tiene acceso a un buffer vulnerable, el atacante puede saltar a libc, esto es, por ejemplo, proporcionar como parámetro el nombre de un programa a ejecutar, e indicar como retorno la dirección de la función system o execve de la libc.

Las secciones de datos no ejecutables son, pues, un obstáculo ante un atacante, aunque no representan una dificultad mucho mayor.

Otra técnica es que, en tiempo de carga y a cada ejecución, el proceso reciba diferentes direcciones base para sus diferentes áreas. Esto hace más difícil para el atacante poder indicar a qué dirección destino se debe saltar.

Un atacante puede emplear varias técnicas para ayudarse a adivinar detalles acerca del acomodo en memoria de un proceso, y, con un buffer suficientemente grande, es común ver cadenas de NOP, esto es, una extensión grande de operaciones nulas, seguidas del shellcode, para aumentar las probabilidades de que el control se transfiera a un punto útil.

Se llama canario a un valor aleatorio de protección²⁶, insertado entre los buffers y la dirección de retorno, que es verificado antes de regresar de una función. Si se presentó un desbordamiento de buffer, el valor del canario será reemplazado por basura, y el sistema podrá detener la ejecución del proceso comprometido antes de que brinde privilegios elevados al atacante. La figura MEM_{overflowcanary} ilustra este mecanismo.

Un atacante tiene dos mecanismos ante un sistema que requiere del canario: Uno es el atacar no directamente a la función en cuestión, sino que al manejador de señales que es notificado de la anomalía, y otro es, ya que se tiene acceso a la memoria del proceso, averiguar el valor del canario. Esto requiere ataques bastante más sofisticados que los vistos en esta sección, pero definitivamente ya no fuera del alcance de los atacantes.

El ligado dinámico puede traer consigo una serie de problemas, entre los cuales se destacan el manejo de versiones de las bibliotecas y potenciales vulnerabilidades. El primer problema es conocido, en ambientes Windows, como el infierno de las DLL. Este infierno se puede causar de muchas formas. Por ejemplo, si al al instalar un nuevo programa, se instala también una versión incompatible de una biblioteca que es usada por otros programas. Esto causa que los demás programas no se puedan ejecutar — Y lo que es más, hace que la depuración del fallo sea muy difícil. Por otro lado, si no se tienen los controles suficientes, al desinstalar un programa se puede borrar una biblioteca compartida, lo cual puede llevar a que otros programas dejen de funcionar.

El infiero de las DLL puede ser prevenido mediante estrategias como el versionamiento de las biblioteca de ligado dinámico (esto es, hacer que cada componente de las bibliotecas lleve la versión que implementa o nivel de compatibilidad que implementa),²⁸ y mediante el uso de scripts de instalación o gestores de dependencias que verifican si existe en el sistema una versión compatible de la biblioteca. Teniendo esta información, la biblioteca en cuestión se instalará únicamente en caso necesario.

El ligado dinámico puede presentar problemas o vulnerabilidades debido a que el programa usa un código proporcionado por terceros, y confía en que la biblioteca funciona tal como se espera sin incluir código malicioso. Por tal razón, desde el punto de vista teórico bastaría que un atacante instale su propia versión de una biblioteca para que pueda tener el control de los programas que la usan e incluso del mismo sistema operativo.²⁹ En el caso de bibliotecas ligadas estáticamente, dado que estas forman ya parte del programa, un atacante tendría que modificar al archivo objeto mismo del programa para alterar las bibliotecas.

Así las cosas, más allá de la economía de espacio en memoria, ¿cómo se explica que sea tanto más popular el ligado dinámico en los sistemas operativos modernos?

Parte muy importante de la respuesta es la mantenibilidad: Si es encontrado un fallo en una biblioteca de carga dinámica, basta con que los desarrolladores lo corrijan una vez (cuidando, claro, de mantener la compatibildad binaria) y reemplazar a dicha biblioteca en disco una sola vez. Todos los programas que liguen dinámicamente con esta biblioteca tendrán disponible de inmediato la versión actualizada. En mucho sistemas operativos, el gestor de paquetes puede detectar cuáles de los procesos en ejecución emplean a determinada biblioteca dinámica, y reiniciarlos de forma transparente al administrador.

En contraste, de estar el fallo en una biblioteca de ligado estático, el código afectado estaría incluído como parte de cada uno de los programas ligados con ella. Como consecuencia, para corregir este defecto, cada uno de los programas afectados tendría que ser recompilado (o, por lo menos, religado) antes de poderse beneficiar de las correcciones.

Y si bien este proceso resulta manual y tedioso para un administrador de sistemas con acceso a las fuentes de los programas que tiene instalados, resulta mucho más oneroso aún para quienes emplean software propietario (En la sección SL_propietario se aborda con mayor detenimiento lo que significa el software propietario en contraposición al software libre).

Cabe mencionar que el comportamiento del sistema ante la actualización de una biblioteca descrita ilustra una de las diferencias semánticas entre sistemas Windows y sistemas Unix que serán abordadas en el capítulo DIR: Mientras un sistema Unix permite la eliminación de un archivo que está siendo utilizado, Windows no la permite. Esto explica por qué las actualizaciones de bibliotecas en sistemas Windows se aplican durante el proceso de apagado: Mientras haya procesos que tienen abierta una biblioteca, ésta no puede ser reemplazada. Caso contrario en sistemas Unix, en que el archivo puede ser reemplazado, pero mientras no sean reiniciados los procesos en cuestión, éstos seguirán ejecutando la versión de la biblioteca con el error.