
Los peligros de carga especulativa potencian los ataques Rowhammer y de caché - CVE-2019-0162 -
https://www.usenix.org/system/files/sec19-islam.pdf
@inproceedings {236252,
author = {Saad Islam and Ahmad Moghimi and Ida Bruhns and Moritz Krebbel and Berk Gulmezoglu and Thomas Eisenbarth and Berk Sunar},
title = {{SPOILER}: Speculative Load Hazards Boost Rowhammer and Cache Attacks},
booktitle = {28th {USENIX} Security Symposium ({USENIX} Security 19)},
year = {2019},
isbn = {978-1-939133-06-9},
address = {Santa Clara, CA},
pages = {621--637},
url = {https://www.usenix.org/conference/usenixsecurity19/presentation/islam},
publisher = {{USENIX} Association},
month = aug,
}
Saad Islam y Ahmad Moghimi, Worcester Polytechnic Institute; Ida Bruhns y Moritz Krebbel, University of Luebeck; Berk Gulmezoglu, Worcester Polytechnic Institute; Thomas Eisenbarth, Worcester Polytechnic Institute y University of Luebeck; Berk Sunar, Worcester Polytechnic Institute
Las microarquitecturas modernas incorporan técnicas de optimización como las cargas especulativas (speculative loads) y el reenvío de almacenamiento (store forwarding) para mejorar el cuello de botella de la memoria. El procesador ejecuta la carga de forma especulativa antes de los almacenamientos y reenvía los datos de un almacenamiento anterior a la carga si existe una posible dependencia. Esto mejora el rendimiento, ya que la carga no tiene que esperar a que se completen los almacenamientos anteriores. Sin embargo, la predicción de dependencias se basa en información parcial de la dirección, lo que puede provocar dependencias falsas y riesgos de bloqueo (stall hazards).
En este trabajo, somos los primeros en demostrar que la lógica de resolución de dependencias que sirve a la carga especulativa puede explotarse para obtener información sobre los mapeos de páginas físicas. Los ataques de canal lateral microarquitectónicos, como Rowhammer, y los ataques de caché, como Prime+Probe, dependen de la ingeniería inversa del mapeo de direcciones virtual a física. Proponemos el ataque SPOILER, que explota esta fuga para acelerar esta ingeniería inversa en un factor de 256. Luego, mostramos cómo esto puede mejorar el ataque Prime+Probe acelerando en un factor de 4096 la búsqueda del conjunto de desalojo (eviction set), incluso desde entornos de espacio aislado (sandbox) como JavaScript. Finalmente, mejoramos el ataque Rowhammer al mostrar cómo SPOILER ayuda a realizar conflictos de fila de DRAM de forma determinista con hasta un 100% de probabilidad, y al demostrar un ataque Rowhammer de doble cara con privilegios de usuario normal. Esto último se debe a la posibilidad de detectar páginas de memoria contiguas mediante la fuga de información de SPOILER.
$ make
$ ./spoiler
Instale gnuplot si aún no está instalado, o trace t2.txt en cualquier otro software. Se proporciona el script de MATLAB plot_t2.m.
$ gnuplot
gnuplot> plot 't2.txt' with lines
Si observa picos similares a los de peaks_linux.png, su CPU es vulnerable a SPOILER. Si no, puede intentar jugar con los parámetros "PAGE_COUNT, WINDOW y THRESH_OUTLIER". Por ejemplo, para una CPU de 11ª generación, cambiar el tamaño de WINDOW a 256 funcionó. La razón puede ser que el tamaño del búfer de almacenamiento (store buffer) aumenta en generaciones más recientes. Por favor, consulte el artículo para más detalles.
Ejecute "spoiler.exe" con doble clic o desde el símbolo del sistema. Si necesita cambiar algún parámetro, vuelva a compilar el código. Trace "t2.txt" con cualquier software o con el script de MATLAB plot_t2.m.