[gull] Attaques sur les CPUs

[Marc SCHAEFER]

Bonjour,

de nombreuses attaques sur les CPU ont été publiées l'an passé et
cette année: elles sont toutes liées, sauf une, à des optimisations
de CPU liées à la micro-architecture x86 ou amd64 (Intel et AMD touché,
avec Intel en général plus sévèrement). [1]

Une concerne le rafraîchissement des DRAMs: dans certaines conditions il
est possible de modifier des bits physiquement adjacents qui peuvent
très bien se trouver dans des zones mémoires privilégiées. [2]

Tous les processeurs ne sont pas concernés de la même façon. Certains
processeurs embarqués ne sont pas concernés.

De nombreux work-arounds ont été publiés à la fois dans les microcodes
de processeur (package non-free intel-microcode dans Debian), dans
les kernels, dans les hyperviseurs (KVM p.ex.) ainsi que pour certains
des modifications de la bibliothèque C standard ou des compilateurs,
nécessitant pour certaines applications des recompilations.

Toutefois, certains de ces problèmes ne sont pas forcément corrigeables:
certains permettent des attaques à long terme permettant p.ex. de voler
des données dans d'autres processus, dans d'autres machines virtuelles,
dans le host, voire même depuis un navigateur avec le Javascript activé --
d'où certains work-arounds dans les navigateurs pour baisser la précision
de certains timers.

Un changement d'architecture est peut-être nécessaire, voire obliger
l'ouverture des spécifications de processeur. [3]

Pour la dernière vague de type d'attaques publiées lundi, si vous tournez
un serveur qui lance du code de tiers (machines virtuelles, code Javascript,
...), soit vous mettez à jour au dernier microcode, au dernier kernel, aux
derniers patches KVM quand ils seront là, etc, ou, une solution un peu
basique existe: désactiver l'hyperthreading en attendant sur vos machines
Intel. Evidemment cela aura un impact sur la charge de vos serveurs. [4]

Voici un script sans garantie, à lancer à chaque démarrage:

#! /bin/bash
# ASSUMPTION
#    - threads_sibling always in the same order, which is what
#      I observed
#    - CPU 0 cannot be disabled, thus always disabling the second
#      sibling
#    - more than two siblings may need to run this script more than once
# BUGS

for i in $(cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list | sort -u | awk -F , '/,/ {print $2;}')
do
   echo 0 > /sys/devices/system/cpu/cpu$i/online
done

[1] https://wiki.alphanet.ch/Sandbox/MeltdownSpectreRowhammer
[2] https://wiki.alphanet.ch/Sandbox/MeltdownSpectreRowhammer#Rowhammer
[3] https://blog.alphanet.ch/entry/110
[4] https://cpu.fail/
    https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html