¿Qué es el error DRAM Rowhammer y cómo debo tratarlo?

Los chips DRAM están muy apretados. La investigación ha demostrado que los bits vecinos se pueden voltear al azar.

¿Cuál es la probabilidad de que el error se active al azar en un chip DRAM de nivel de servidor con ECC (el documento CMU-Intel cita, por ejemplo, el número 9.4x10 ^ -14 para un chip desconocido por un fallo en un año)?
¿Cómo sé si el error se soluciona antes de comprar memoria?
¿Qué debo hacer para contrarrestar los intentos maliciosos de escalar privilegios, por ejemplo, por inquilinos o usuarios sin privilegios, por ejemplo, en CentOS 7?

Referencias

— Cazador de ciervos
fuente

Dado que los detalles del exploit aún no se han embargado, no estoy seguro de que haya mucha información disponible, aparte de lo que Google ya le ha dado.

— fukawi2

Tal como lo entendí, la frecuencia de actualización de memoria reduce drásticamente las probabilidades de un cambio de bit exitoso, y las versiones más recientes de BIOS han reducido las tasas de actualización para tratar de mitigar el riesgo. Entonces, ¿actualizar su BIOS podría ser un buen primer paso?

— Reaces

@ fukawi2, ¿qué detalles del exploit fueron / son embargados? El código completo para las hazañas de prueba de concepto fue publicado con la publicación del blog.

— Mark Seaborn

@MarkSeaborn Ni siquiera recuerdo ahora, esto fue hace 3 meses, y apenas puedo recordar el desayuno.

— fukawi2

Respuestas:

El documento CMU-Intel que citó muestra (en la página 5) que la tasa de error depende en gran medida del número de pieza / fecha de fabricación del módulo DRAM y varía en un factor de 10-1000. También hay algunos indicios de que el problema es mucho menos pronunciado en los chips fabricados recientemente (2014).

El número '9.4x10 ^ -14' que citó se usó en el contexto de un mecanismo de mitigación teórico propuesto llamado "PARA" (que podría ser similar a un mecanismo de mitigación pTRR existente (pseudo Target Row Refresh)) y es irrelevante para su pregunta, porque PARA no tiene nada que ver con ECC.

Un segundo papel CMU-Intel (página 10) menciona los efectos de diferentes algoritmos ECC en la reducción de errores (factor 10 ^ 2 a 10 ^ 5, posiblemente mucho más con pruebas de memoria sofisticadas y "bandas de protección").

ECC efectivamente convierte el exploit Row Hammer en un ataque DOS. El ECC corregirá los errores de 1 bit, y tan pronto como se detecte un error de 2 bits no corregible, el sistema se detendrá (suponiendo un ECC SECDED).

Una solución es comprar hardware que admita pTRR o TRR. Vea la publicación de blog actual de Cisco sobre Row Hammer . Al menos algunos fabricantes parecen tener uno de estos mecanismos de mitigación integrados en sus módulos DRAM, pero lo mantienen profundamente oculto en sus especificaciones. Para responder a su pregunta: pregúntele al vendedor.

Las velocidades de actualización más rápidas (32 ms en lugar de 64 ms) y los intervalos agresivos de Patrol Scrub también ayudan, pero tendrían un impacto en el rendimiento. Pero no conozco ningún hardware de servidor que realmente permita ajustar estos parámetros.

Supongo que no hay mucho que pueda hacer en el lado del sistema operativo, excepto terminar procesos sospechosos con un uso constante de CPU alta y fallas en la memoria caché.

— Daniel
fuente

La situación todavía parece poco clara, por lo que no creo que sus preguntas puedan responderse directamente, pero aquí hay información relativamente reciente como respuesta parcial. Para noticias, siga el debate de martillo de fila lista de correo de .

No estoy seguro de que actualmente sea posible con información pública evitar comprar RAM vulnerable, ni predecir fácilmente las tasas de falla en el hardware existente. Los fabricantes no han sido abiertos con información sobre cómo se ven afectados sus productos. Es posible probar la memoria ya comprada usando herramientas de software, pero debe tener en cuenta que ejecutar esas herramientas durante períodos significativos (horas) puede degradar permanentemente la RAM y causar fallas en la ejecución del software.

Según los informes, "compañías de memoria sin nombre" han intentado pagar un soborno a cambio de que Passmark Software no haya lanzado una prueba de martillo en su herramienta Memtest86.

Se ha informado que el hardware Intel Skylake es más vulnerable, no menos , al martillo de remo debido a la incorporación de una nueva clflushoptinstrucción. Esto ya ha sido explotado en rowhammer.js

Daniel Gruss responde algunas preguntas aquí sobre mitigación a diciembre de 2015 (coautor del artículo rowhammer.js ) en esta charla :

Mientras que algunos RAM ECC son menos vulnerables que los que no son ECC al martillo de remo, otros ECC RAM son más vulnerables que los que no son ECC ( enlace a la pregunta en video )
Cambiar a una frecuencia de actualización más rápida es suficiente para evitar el martillo de remo con la mayoría pero no todo el hardware, pero no todas las BIOS permiten cambiar la frecuencia de actualización ( enlace a pregunta en video ).

Como contramedida, puede ser posible detectar ataques de martillo en fila en progreso, pero no sé si eso se haya hecho.

— Croad Langshan
fuente