Después de mucho tiempo de desarrollo debido a las numerosas críticas en cuanto al recolector de basura del lenguaje de programación D, las interfaces interfaces personalizables de reserva/liberación de memoria para dicho lenguaje de programación está listas para ser revisadas por la comunidad.

Dr. Memory es un depurador de problemas de memoria para Windows, Linux y Mac capaz de identificar diferentes tipos de errores relacionados con la memoria, como accesos a memoria no inicializada, accesos a memoria no direccionable, accesos a memoria ya liberada, doble liberación de memoria, fugas de memoria, etc. Esta herramienta tiene licencia LGPL.

Este es el primer artículo de una serie sobre comunicación entre procesos (IPC) en Linux. La serie utiliza ejemplos de código en C para aclarar los siguientes mecanismos de IPC: archivos compartidos; memoria compartida (con semáforos); pipes (con nombre y sin nombre); colas de mensajes; sockets; y señales. Este artículo revisa algunos conceptos básicos antes de continuar. Los dos primeros de estos mecanismos: archivos compartidos y memoria compartida.

En 1978, un chip de memoria almacenaba solo 16 kilobits de datos. Para hacer un chip de memoria de 32 kilobits, Mostek tuvo la idea de colocar dos chips de 16K en un portador del tamaño de un circuito integrado estándar, creando el primer módulo de memoria, el MK4332 "RAM-pak". Este módulo permitió a los fabricantes de computadoras duplicar la densidad de sus sistemas de memoria, y en 1982 Mostek había vendido más de 3 millones de esos módulos. El Apple III es el sistema más conocido que utilizó dichos módulos de memoria.

Critico frencuentemente los lenguajes inseguros respecto a la memoria, principalmente C y C++, especialmente cómo inducen un número excepcional de vulnerabilidades de seguridad. Mi conclusión, basada en la revisión de la evidencia de numerosos proyectos de software grandes que utilizan C y C++, es que debemos migrar nuestra industria a lenguajes seguros respecto al uso de la memoria (como Rust y Swift). Una de las respuestas que recibo con frecuencia es que el problema no son C y C++ en sí mismos, sino que los desarrolladores se equivocan. Desafortunadamente mi experiencia en grandes proyectos me indica que hay mucho C++ totalmente moderno que introduce vulnerabilidades.

A raíz de la publicación de la noticia del lanzamiento del Kernel 4.12 de Linux, el cual trae por primera vez activada por defecto la característica KASLR, y casi simultáneamente la publicación de otra noticia sobre la implementación de una característica llamada KARL en OpenBSD, me ha parecido que sería interesante aclarar las diferencias entre estas técnicas de seguridad, pues pienso que la combinación de ambas va a ser muy importante de cara al futuro de la seguridad de los sistemas, pues van a impedir explotar vulnerabilidades relacionadas con la corrupción de memoria (buffer overflow). Pero antes de entrar a detallar las características de KASLR y KARL, echemos un vistazo ASLR.