ZenHammer: ataques Rowhammer en plataformas basadas en AMD Zen

Artículo original ↗ Discusión en Hacker News ↗

DDR5, ECC en chip y la “fragilidad” de la DRAM moderna

  • Varios comentarios señalan que el ECC en chip de DDR5 es necesario para que la tecnología sea fiable a sus mayores densidades y velocidades.
  • Algunos argumentan que esto no es algo “negativo”, sino parte de una tendencia general: todo el almacenamiento se vuelve probabilístico y luego se corrige con matemáticas.
  • Otros describen DDR5 como “frágil” porque los tamaños de celda y los márgenes temporales se llevan tan al límite que algunos bits fallarían de otro modo; se usa ECC en lugar de reducir rendimiento/densidad.
  • Hay debate sobre si DDR5 está “mayormente arreglada” para Rowhammer; el artículo muestra cambios de bit en al menos un dispositivo DDR5, pero los ataques solo tuvieron éxito en 1 de 10 módulos DDR5 probados y requieren más investigación.

Rowhammer como fenómeno físico y modelo de amenaza

  • Rowhammer se presenta como un problema de física de la DRAM: accesos repetidos a una fila provocan fuga de carga y cambios de bit en filas vecinas.
  • Celdas más pequeñas, densas y cercanas facilitan los ataques, pero también hacen la RAM más barata, rápida y eficiente.
  • Algunos dicen que este es un resultado “inevitable” de la presión de toda la industria por la densidad y el coste, no solo de una “negligencia orientada a maximizar beneficios”.

Riesgo real para usuarios normales

  • Muchos sostienen que es poco probable que los usuarios promedio se vean directamente afectados; los ataques típicos contra ellos son exploits de software y malware más simples.
  • Otros subrayan que Rowhammer y fallos similares se han demostrado desde JavaScript en navegadores, en máquinas virtuales, teléfonos e incluso a través de redes; que no se haya observado explotación masiva no significa riesgo cero.
  • El bloqueo de scripts (NoScript, uBlock, JS desactivado por defecto) se discute como mitigación práctica, aunque algunos lo consideran demasiado incómodo.

ECC como mitigación

  • Existe un fuerte consenso en que ECC eleva significativamente el listón: muchos cambios simples o dobles pasan a ser corregibles o hacen que el sistema falle, convirtiendo un exploit sigiloso en un problema de fiabilidad evidente.
  • Quienes critican “ECC no ayuda” consideran esa formulación engañosa; el éxito del ataque suele requerir entonces muchos parones de máquina o registros de errores detectables.
  • Una salvedad importante: el reporte y el tratamiento de ECC varían según la plataforma; algunas plataformas de escritorio/consumo corrigen en silencio o no exponen contadores vía IPMI, aunque el manejo de Machine Check a nivel del sistema operativo sigue existiendo en muchas configuraciones.

ECC de AMD/Intel y opciones de plataforma

  • AMD Ryzen de escritorio tiene soporte ECC (ahora oficialmente), pero que funcione depende de la placa base. ASRock y ASUS se citan con frecuencia como fabricantes que lo habilitan en placas AM5.
  • El ECC en portátiles se limita en gran medida a costosas “workstations móviles” y SKU Pro; las generaciones móviles recientes de AMD tuvieron soporte ECC cambiante y poco claro en las especificaciones públicas.
  • La DDR5 ECC sin búfer es significativamente más cara (a menudo con una prima de ~50–100%) y carece de binning de overclock/XMP de fábrica, por lo que los usuarios pueden necesitar ajustes manuales para el rendimiento.
  • Threadripper admite ECC registrado y se ve como excelente pero excesivo (coste, número de núcleos, líneas PCIe) para muchos usuarios domésticos.

Cifrado de memoria y otras defensas

  • Se dice que el cifrado de memoria (por ejemplo, AMD SEV/Secure Memory Encryption) impide que Rowhammer se convierta en corrupción de datos dirigida; los cambios de bit se vuelven aleatorios en el cifrado, probablemente causando fallos en lugar de exploits controlados.
  • Esto puede hacer que los sistemas sean menos “gráciles” (cambios de un solo bit que provocan errores fatales), pero más obviamente rotos, lo que se considera preferible desde el punto de vista de la seguridad.

Contexto más amplio de seguridad y privacidad

  • Varios comentarios contrastan los ataques de hardware altamente técnicos con los riesgos mucho mayores y continuos del rastreo omnipresente, los intermediarios de datos y los dispositivos IoT inseguros.
  • Algunos argumentan que la sociedad necesita con más urgencia una regulación amplia de la privacidad que mitigaciones cada vez más marginales para fallos exóticos de hardware.