Qu'est-ce que le bogue Rowhammer DRAM et comment dois-je le traiter?

Les puces DRAM sont très bien emballées. La recherche a montré que les bits voisins peuvent être retournés au hasard.

Quelle est la probabilité que le bogue se déclenche au hasard dans une puce DRAM de qualité serveur avec ECC (le papier CMU-Intel cite par exemple le nombre 9.4x10 ^ -14 pour une puce inconnue pour une défaillance dans un an)?
Comment savoir si le bogue est résolu avant d'acheter de la mémoire?
Que dois-je faire pour contrer les tentatives malveillantes de faire une escalade de privilèges par exemple des locataires ou des utilisateurs non privilégiés sur par exemple CentOS 7?

Les références:

— Chasseur de cerf
source

Étant donné que les détails de l'exploit n'ont pas encore fait l'objet d'un embargo, je ne suis pas sûr qu'il y aura beaucoup d'informations disponibles en dehors de ce que Google vous a déjà donné.

— fukawi2

Si je comprends bien, le taux de rafraîchissement de la mémoire réduit considérablement les chances d'un basculement de bits réussi, et les nouvelles versions du BIOS ont réduit les taux de rafraîchissement pour essayer d'atténuer le risque. La mise à jour de votre BIOS pourrait donc être une bonne première étape?

— Réagit

@ fukawi2, quels détails de l'exploit ont été / sont sous embargo? Le code complet pour les exploits de preuve de concept a été publié avec le billet de blog.

— Mark Seaborn

@MarkSeaborn Je ne me souviens même pas maintenant, c'était il y a 3 mois, et je me souviens à peine du petit déjeuner.

— fukawi2

Réponses:

Le document CMU-Intel que vous avez cité montre (à la page 5) que le taux d'erreur dépend fortement du numéro de pièce / date de fabrication du module DRAM et varie d'un facteur 10-1000. Il semble également que le problème soit beaucoup moins prononcé dans les puces fabriquées récemment (2014).

Le nombre «9.4x10 ^ -14» que vous avez cité a été utilisé dans le contexte d'un mécanisme d'atténuation théorique proposé appelé «PARA» (qui pourrait être similaire à un mécanisme d'atténuation existant pTRR (pseudo Target Row Refresh)) et n'est pas pertinent pour votre question, parce que PARA n'a rien à voir avec ECC.

Un deuxième article CMU-Intel (page 10) mentionne les effets de différents algorithmes ECC sur la réduction des erreurs (facteur 10 ^ 2 à 10 ^ 5, peut-être beaucoup plus avec des tests de mémoire sophistiqués et des "bandes de garde").

ECC transforme efficacement l'exploit Row Hammer en une attaque DOS. Les erreurs 1 bit seront corrigées par ECC, et dès qu'une erreur 2bit non corrigeable est détectée, le système s'arrêtera (en supposant SECDED ECC).

Une solution consiste à acheter du matériel prenant en charge pTRR ou TRR. Voir le billet de blog actuel de Cisco sur Row Hammer . Au moins certains fabricants semblent avoir l'un de ces mécanismes d'atténuation intégré dans leurs modules DRAM, mais le gardent profondément caché dans leurs spécifications. Pour répondre à votre question: demandez au vendeur.

Des taux de rafraîchissement plus rapides (32 ms au lieu de 64 ms) et des intervalles de nettoyage de patrouille agressifs aident également, mais auraient un impact sur les performances. Mais je ne connais aucun matériel serveur qui permette réellement de peaufiner ces paramètres.

Je suppose qu'il n'y a pas grand-chose que vous puissiez faire du côté du système d'exploitation, sauf mettre fin aux processus suspects avec une utilisation constante élevée du processeur et des échecs de cache élevés.

— Daniel
source

La situation semble encore assez floue, donc je ne pense pas que l'on puisse répondre directement à vos questions, mais voici quelques informations relativement récentes comme réponse partielle. Pour des nouvelles, suivez la liste de diffusion Rowhammer-discuter .

Je ne suis pas sûr qu'il soit actuellement possible, avec des informations publiques, d'éviter d'acheter de la RAM vulnérable, ni de prédire facilement les taux de défaillance du matériel existant. Les fabricants n'ont pas été ouverts avec des informations sur la façon dont leurs produits sont affectés. Il est possible de tester la mémoire déjà achetée à l'aide d'outils logiciels, mais vous devez savoir que l'exécution de ces outils pendant des périodes importantes (heures) peut dégrader définitivement la RAM et provoquer des erreurs dans l'exécution des logiciels.

Des "sociétés de mémoire sans nom" auraient tenté de verser un pot- de- vin en échange de la non-publication par Passmark Software d'un test de marteau dans leur outil Memtest86.

Il a été rapporté que le matériel Intel Skylake est plus vulnérable, pas moins , aux coups de bélier en raison de l'ajout de l'ajout d'une nouvelle clflushoptinstruction. Cela a déjà été exploité dans rowhammer.js

Daniel Gruss répond ici à quelques questions sur l'atténuation à partir de décembre 2015 (co-auteur du document rowhammer.js ) dans cette conférence :

Alors que certains RAM ECC sont moins vulnérables que les RAM non-ECC au marteau, d'autres RAM ECC sont plus vulnérables que les RAM non-ECC ( lien vers la question en vidéo )
Le passage à un taux de rafraîchissement plus rapide est suffisant pour empêcher le tapage avec la plupart mais pas tout le matériel - mais tous les BIOS ne permettent pas de changer le taux de rafraîchissement ( lien vers la question en vidéo ).

À titre de contre-mesure, il peut être possible de détecter des attaques au marteau en cours, mais je ne sais pas si cela a été fait.

— Croad Langshan
source