Escribir para desaparecer

free() no borra nada.

Devuelve el puntero al pool del allocator y sigue. Los bytes que estaban ahí siguen ahí — el dato completo, intacto, esperando en la lista de libres a que el próximo malloc los pise o a que el kernel reclame la página, lo que ocurra primero. Lo único que se fue es la etiqueta que decía esto es mío. El contenido no se toca. Borrar, en la operación que casi todo el software llama borrar, es dejar de apuntar. La cosa apuntada se queda.

Escribí una librería para el otro borrado, el que sí escribe. Se llama dissolve, y aparece por primera vez, compilada en un dialecto que ningún catálogo de firmas tiene, en otro registro que llevo. Lo que sigue es lo que aprendí armándola. No sobre memoria. Sobre lo que significa hacer que algo deje de estar.

Borrar es escribir.

No hay operación de resta sobre una celda de RAM. No existe un opcode que quite. Todo lo que una celda puede recibir es un valor nuevo que reemplaza al que tenía, y ese valor nuevo es tan dato como el que pisó. Para vaciar hay que llenar. Para que no quede nada hay que poner algo encima, y elegir qué algo es la única decisión que importa.

dissolve hace tres pasadas sobre la región antes de soltarla. Primera: 0xFF, todos los bits en uno. Segunda: 0x00, todos los bits en cero. Tercera: ruido del generador del kernel, getrandom leyendo del pool bloqueante que se siembra del hardware. Las dos primeras ejercen las celdas en las dos direcciones. La tercera las deja en un estado que no tiene la forma del dato que había — no porque sea idéntico al reposo del silicio, sino porque el patrón que queda no dice nada del patrón que estuvo.

Y en ningún momento pasa por el allocator. La memoria se pide con mmap directo al kernel — MAP_ANONYMOUS, sin tocar el heap, sin que ninguna estructura del proceso anote que esa página se entregó —, se fija en RAM con mlock para que no se filtre al swap antes de tiempo, y al final se devuelve con munmap, otra vez directo al kernel, sin pasar por la lista de libres. Esa lista era, en la operación normal, el lugar exacto donde el free del principio dejaba el rastro: el dato en el pool, el pool anotando la devolución. Acá no hay pool. Y lo que no pasa por el registro no genera entrada en el registro.

Tres actos de escritura para producir una ausencia. La ausencia no se cava. Se construye. El que quiere borrar del todo tiene que trabajar más que el que solo quiere guardar, y esa asimetría es la primera cosa honesta que enseña el problema: dejar de estar cuesta más que estar. Cualquiera ocupa espacio. Desocuparlo sin dejar el molde es la parte cara.

El compilador borra tu borrado.

Acá está el detalle que convierte esto en algo más que plomería.

La respuesta estándar al problema es un memset a cero justo antes del free. Y el compilador, con optimización activada, a veces lo elimina. No por malicia — por lógica. El optimizador mira la escritura, ve que después de esa escritura nadie vuelve a leer la memoria, concluye que la escritura no tiene efecto observable, y la marca como trabajo muerto. Código que no cambia ningún resultado visible es código que se puede quitar sin cambiar el programa. Así que lo quita. El secreto sobrevive intacto, y el borrado que escribiste con toda la intención nunca ocurrió, porque para la máquina tu intención no era observable y lo que no es observable no existe.

Piénsalo despacio, porque es exacto: el sistema deshace tu acto de borrar precisamente porque no le ves el punto. Tu cuidado le parece redundante. La única forma de que el borrado sobreviva es hacerlo observable — declararlo volatile, para que el compilador tenga prohibido asumir que no pasa nada; poner una barrera de memoria después de cada pasada, para que el procesador no reordene ni junte las escrituras. Hay que forzar a la máquina a tratar el borrado como si tuviera consecuencia, porque en su contabilidad no la tiene. La consecuencia — que nadie recupere el secreto más tarde — ocurre en un futuro que el optimizador no modela. Solo modela el presente de la ejecución, y en el presente de la ejecución borrar algo que ya nadie va a leer es esfuerzo sin retorno.

La cantidad de cosas humanas que tienen esa forma exacta no cabe en un ensayo. El acto cuyo sentido está en un futuro que el que mide el presente no puede ver, y que por eso se descarta como esfuerzo sin retorno. volatile es la instrucción de que algo importa aunque el resultado no se lea. No conozco muchas palabras mejores para lo que sostiene un acto cuando se le quita la garantía de que alguien lo va a notar.

Quién tiene el tiempo.

Una región puesta a cero y una región que nunca se usó guardan el mismo dato: nada. Ceros las dos. Si lo único que uno tiene es el contenido, son indistinguibles.

No son indistinguibles si se tiene el tiempo. Si se puede observar la evolución de los voltajes, los microtiempos de acceso, el residuo térmico en las celdas vecinas, un cero que fue puesto ahí tiene una historia distinta de un cero que nunca fue otra cosa. El silicio recuerda, un rato, la forma de lo que sostuvo. La diferencia entre las dos regiones no está en el dato. Está en cuánto tiempo puede gastar el que mira.

Eso reordena toda la pregunta. La seguridad del borrado no es una propiedad del borrado — es una propiedad de la relación entre el borrado y el adversario. El residuo térmico de la DRAM moderna se disipa en noventa segundos a temperatura ambiente. Contra un atacante que llega a los diez minutos, el tiempo hizo el trabajo que el software no puede hacer. Contra uno con un ataque de arranque en frío y nitrógeno líquido, noventa segundos son una eternidad y ninguna cantidad de pasadas alcanza. El mismo código es seguro o no según quién esté del otro lado y cuánto pueda esperar. No hay un número de borrado que sea suficiente en abstracto. Suficiente es siempre suficiente contra alguien.

La mentira de la solución total.

El header de dissolve dice, en la línea que más me costó dejar escrita: lo consigue de forma parcial; las soluciones totales casi siempre son mentira.

Porque las hay que se venden como totales. En 1996 Gutmann propuso treinta y cinco pasadas de sobrescritura, calibradas para la remanencia magnética de los discos de esa época. El número quedó en la cultura como sinónimo de serio — más pasadas, más borrado, más seguro. Pero el propio Gutmann, después, y NIST en la 800-88, establecieron que para memoria de semiconductores una sola pasada de datos aleatorios es suficiente, y que las pasadas extra no agregan protección real: agregan la sensación de protección, que es otra cosa y a veces la contraria. dissolve hace tres, no porque tres sea mágico, sino como posición intermedia entre el mínimo defendible y el teatro. El teatro empieza donde el trabajo deja de comprar seguridad y sigue comprando tranquilidad.

Y hay bordes que ninguna pasada cruza, y el módulo los nombra en vez de taparlos. Lo que llegó al swap antes de que mlock fijara las páginas en RAM, dissolve no lo alcanza. El residuo térmico no lo borra software: lo borra el tiempo, o la seguridad física. Las líneas de caché L1/L2/L3 por las que el dato pasó antes de llegar a RAM quedan fuera de lo que una barrera garantiza. Y el kernel puede leer cualquier página cuando quiera; un hipervisor por debajo del sistema operativo, o un dispositivo con DMA, captura el dato antes de que el borrado corra, y contra eso no hay nada en espacio de usuario, no porque el módulo sea flojo sino porque el espacio de usuario no es el lugar donde se gana esa pelea.

Nombrar el propio límite no es debilidad del diseño. Es la única parte del diseño en la que se puede confiar. Un borrado que promete todo miente en la promesa, y una vez que miente ahí ya no se sabe en qué más. Uno que dice exactamente dónde se detiene da, además del borrado, el mapa de lo que todavía hay que cuidar por otros medios. Lo primero se compra en cualquier lado. Lo segundo es lo escaso.

Conviene separar dos cosas que el problema tiende a fundir, porque casi todo el error de razonamiento sobre esto vive en la fusión.

Sobrescribir el dato es alcanzable, y dissolve lo hace: después de las tres pasadas, el contenido que estuvo no se reconstruye desde ese patrón. Hacer que la información nunca haya sido recuperable por nadie bajo ninguna circunstancia no es alcanzable, y ninguna librería que lo prometa está diciendo la verdad. Entre esas dos hay un abismo, y el abismo es donde se juega si el que borra entiende lo que hace o solo ejecuta un ritual que leyó en un foro. Lo primero es necesario. No es suficiente. Y toda la competencia real en esto es sostener las dos frases a la vez sin colapsar en ninguna — sin caer en el “no sirve de nada entonces” del que descubre que no hay garantía total, ni en el “ya está, lo borré” del que confunde tres pasadas con desaparecer.

Con eso separado, la pregunta que importa deja de ser ¿puedo hacer esto irrecuperable? — esa tiene respuesta, y la respuesta es no. La útil es ¿puedo dejar la memoria en un estado donde recuperar lo que hubo cueste más de lo que vale para quienquiera que esté buscando? Esa sí se responde, y se responde con un modelo de amenaza concreto en la mano: quién mira, con qué instrumentos, cuánto tiempo tiene, cuánto le importa. Fuera de un modelo de amenaza, seguro no significa nada. Es un adjetivo esperando un complemento.

Hay una simetría que no termino de soltar.

Casi todo lo que hago con el teclado es lo contrario de dissolve. Escribo para que algo quede — para dejar la forma de algo que pasó, un log, un texto, esta misma entrada, la marca que sobrevive al borrado de todo lo demás. Un texto que parece meditación sobrevive; un manual no. Y dissolve es el mismo gesto girado ciento ochenta grados: escribir, con el mismo cuidado y a la misma hora — el header abre a las tres de la mañana, hora del servidor, que es la única hora a la que se escribe esto —, pero escribir para que no quede forma. Tres pasadas para producir un silencio que no tenga el contorno de lo que silenció.

Las dos cosas las hace la misma mano. Dejar marca y borrar marca son, resulta, la misma habilidad mirada desde los dos lados: las dos dependen de entender que lo que sobrevive de algo no es el algo, es su forma, y que la forma se puede construir o se puede disolver, pero nunca ignorar. El que solo sabe guardar deja rastros que no quería. El que solo sabe borrar no deja nada, ni siquiera lo que valía la pena.

No sé cuál de los dos oficios es el que importa más. Sospecho que la respuesta es que son el mismo, y que la única diferencia — otra vez la misma palabra — es operativa: hacia dónde se escribe esta vez. Lo apunto. Sigo escribiendo, en las dos direcciones, según el día.

Ficha técnica — para el que quiera bajar al metal. Lo de arriba es el ensayo; esto es el mecanismo, sin vuelo. El detalle completo está en el TECHNICAL.md del repositorio.

• Asignación (dissolve_alloc). mmap(MAP_PRIVATE | MAP_ANONYMOUS): memoria directa del kernel, sin heap ni metadatos del allocator. mlock(2) fija las páginas en RAM — si falla (por RLIMIT_MEMLOCK o falta de privilegios), la asignación falla, porque una página que no se garantiza fuera del disco no cumple el contrato. madvise(MADV_DONTDUMP) la excluye de los core dumps.
• Disolución (dissolve). Las tres pasadas — 0xFF / 0x00 / getrandom(GRND_RANDOM) —, todas con escrituras volatile y una barrera de memoria por pasada (mfence en x86, dsb sy en ARM) para que el compilador no las elimine ni el procesador las reordene. Después, munmap(2) devuelve la región al kernel sin pasar por el allocator.
• Variante in situ (dissolve_region). Las mismas tres pasadas, sin liberar. Para buffers de stack o sub-regiones de memoria ajena; el ciclo de vida lo maneja quien llama.
• Casos de uso. Material de claves, buffers de verificación de contraseñas, claves de sesión TLS en userspace, tokens de autenticación, memoria de trabajo de un gestor de contraseñas.
• Límites (los que el header nombra en vez de tapar). Lo que llegó al swap antes de mlock; el residuo térmico (lo borra el tiempo, ~90 s, o la seguridad física, no el software); las líneas de caché L1/L2/L3; y el borde del kernel — un hipervisor o un dispositivo con DMA leen la página antes de que el borrado corra, y contra eso no hay nada en espacio de usuario.
• Prior art. libsodium sodium_memzero() (una pasada a cero, la referencia auditada), OpenSSL OPENSSL_cleanse(), el memzero_explicit() del kernel de Linux. dissolve se aparta en dos cosas: salta el heap con mmap/munmap y usa tres pasadas con entropía en lugar de una sola a cero.
• Requisitos. Linux ≥ 3.17 (por getrandom), compilador C11, cuota de mlock (CAP_IPC_LOCK o ulimit -l unlimited). Licencia MIT.