Diskussion:Rowhammer

In dem deutschen Artikel stimmt so ziemlich gar nichts

Erstens ist das Problem schon seit Jahren bekannt und Rowhammer bezeichnet auch nicht den Angriff sondern den Effekt. Und der Effekt ensteht auch nicht beim Schreiben sondern beim Lesen. DDR-Speicher vor DDR3 ist nicht betroffen. ECC verhindert das Problem auch nicht. Wie gesagt: In dem Artikel stimmt so ziemlich gar nichts. --77.8.105.106 01:10, 13. Mär. 2015 (CET)

Der Angriff kann überhaupt nicht seit 2003 bekannt sein, weil es 2003 noch überhaupt keinen DDR3-Speicher gab. Das Phänomen Row Hammer, welches im Artikel hier falsch dargestellt ist, weil damit nicht das Angriffszenario des Google Security Teams gemeint ist, ist mindestens seit 2012 bekannt: http://www.google.com/patents/US20140006704 Auch 2014 findet man Quellen, die sich damit beschäftigen: https://web.archive.org/web/20140329024004/http://teledynelecroy.com/protocolanalyzer/protocoloverview.aspx?seriesid=398 --2001:5C0:1400:A:0:0:0:67B 21:27, 14. Mär. 2015 (CET)

Also ich zitiere mal aus dem Artikel bei pro-linux.de

„Auch wenn das Problem nun technisch greifbar ist, Grund zur Panik gibt es noch nicht. Denn das Problem der »kippenden« Bits ist nicht neu. Bereits 2003 haben Sudhakar Govindavajhala und Andrew W. Appel von der Princeton University in ihrem Whitepaper »Using Memory Errors to Attack a Virtual Machine« gezeigt, wie Bitfehler für Ausbrüche oder Angriffe genutzt werden können“

– Marko Lindner: pro-linux.de

Sinngemäß wird dort beschrieben, wie man aus der JVM durch Manipulation des DRAMs durch Bitflips aus der VM ausbrechen kann (habe allerdings die Studie nur überflogen). Stellt sich die Frage, ob Seaborn den ersten praktischen Angriff außerhalb der JVM durchgeführt hat, oder wo seine "Neuentdeckung" besteht. Lasse mich gerne eines besseren belehren. --Speedpera (Diskussion) 10:38, 15. Mär. 2015 (CET)

Zitat aus der Studie von 2003:
"1. We ran a privileged Java thread inside the JVM that uses the Java Native Interface to a C-language function that flips a bit in the process address space.[...]
2. We ran an unmodified JVM, with a separate privileged Linux process that opens /dev/mem and flips a random bit in the computer’s physical memory. This simulates a naturally induced memory error that results from a cosmic ray, as described in Section 6.
3. We ran an unmodified JVM, and induced memory errors by heating the memory to 100◦C, as described in Section 7."

Was hat das mit dem Row-Hammer-Effekt zu tun? Gar nichts, denn Sie benutzen nicht "Row Hammer" zum Kippen der Bits, denn das konkrete Problem gab es ja damals auch noch nicht. Row Hammer steht nicht für "aus einer VM aufgrund von Bitfehlern auszubrechen". Der Effekt von kippenden Bits in DDR3 aufgrund von wiederholten Lesezugriffen auf die gleichen Speicherzellen ist schon seit Jahren (etwa seit 2012) bekannt. Der blumige, bildsprachliche Ausdruck "Hammern" steht dafür, dass die Zelle nach jedem Auslesen wieder aufgefrischt werden muss, weil der Lesevorganz die Ladung der Zelle senkt. Durch sehr häufiges Auslesen in kurzem Zeitraum, kann es dazu kommen, dass die Zelle überladen wird und die Ladung auch aufgrund der extreme hohen Dichte in benachbarte Zellen überspringt. Das ist "Row Hammer". Später hat sich dann das Team von Google angeschaut, ob und wie man "row hammer" in Software erzeugen kann. Eigentlich wird dies ja durch die Caches verhindert, so dass wiederholtes Lesen gar nicht beim DRAM-Modul ankommt. Durch CPU-Befehle, die das Cache-Verhalten steuern ist dies teilweise doch möglich. Als Anwendung dieses Problems haben Sie nun das Ausbrechen aus einer VM programmiert. Nochmal: Dies ist aber nicht "Row Hammer" sondern ein spezieller Exploit der diesen Effekt namens "Row Hammer" ausnutzt. Das Ausbrechen aus einer VM bzw. illegale Veränderungen am Speicherinhalt könnte man auch auf andere Weise erzeugen. Drei davon sind in der Studie aus 2003 aufgeführt. Andere Möglichkeiten wären Bugs in Hardware- und Treibern, die DMA-Transfers nutzen, Kernel-Bugs oder Lese/Schreibfehler beim Paging. Hier geht es auch mehr darum zu zeigen, wie fatal einzelne Bitfehler die Sicherheit einer VM aushebeln können und nicht darum, diese Bitfehler zu erzeugen. Dass ein Root-Prozess samtlichen Speicher beliebig manipulieren kann, ist ein Feature und kein Bug.

Des Weiteren ist konventioneller ECC auch nicht die Lösung für das Problem "Row Hammer", weil es nur eine begrenzte Zahl von Fehler erkennen und noch weniger korrigieren kann. ECC versteckt das Problem bestenfalls so wie es Cache normalerweise verhindert. Die Lösung, die wohl auch einige Hersteller von DDR3-Speicher in ihre Chips eingebaut haben, besteht darin, das Überladen der Zellen durch zusätzliche Logik im DRAM selbst zu verhindern. Ganz offensichtlich sind nicht alle Systeme mit DDR3-Speicher betroffen. Gerade in der Nicht-Fach-Presse, die den Begriff "Row Hammer" sowieso das erste Mal wahrnimmt, werden die Begriffe leider quer durcheinander geworfen. Aber ich weiß das meiste darüber auch bloß durchs Googlen. --77.8.105.106 16:30, 15. Mär. 2015 (CET)

Abwehrmethoden

Dort steht aktuell: Abwehrmethoden Da diese Sicherheitslücke Eigenheiten der Hardware ausnutzt, ist eine Behebung nicht durch einfache Softwarelösungen wie etwa den Wechsel des Virenscanners oder des Betriebssystems möglich. Einen denkbaren Schutz vor einem Rowhammer-Angriff stellt fehlerkorrigierende Hardware, wie etwa ECC-Speichermodule, dar.[2]

Der Begriff "ECC Speichermodule" impliziert, dass man einfach nur spezielle ECC Speichermodule bräuchte. Aber tatsächlich wird die Fehlerkorrektur nicht von den Modulen ausgeführt, sondern vom Memory Controller, der sich innerhalb der CPU bzw des Chipsets befindet. Es werden also ZWEI Dinge benötigt: Eine ECC-fähige CPU bzw Chipset und dazu Speicher mit geeigneter Bit-Breite zur Ablage der Daten + der ECC-Prüfbits. Der Speicher muss auch nicht zwingend in Modulform sein, sondern kann genauso auch aufgelötet sein.

Ich würde hier also korrigieren in: "Einen denkbaren Schutz vor einem Rowhammer-Angriff stellt die ECC-Fehlerkorrektur dar. Dazu sind ECC-fähige Prozessoren nötig und dazu passender Speicher mit erweiterter Bit-Breite. Alternativ gibt es auch selbsttägig fehlerkorrigierende Speicher, sogenannte ECC DRAMs [NEUE REFERENZ]"

Die NEUE REFERENZ kann man aus dem englischen Wikipedia-Eintrag zu ECC Memory ziehen http://en.wikipedia.org/wiki/ECC_memory Siehe bitte dort die Quelle Nummer 19 "ECC DRAM – Intelligent Memory". Link: www.intelligentmemory.com/ECC-DRAM/

Zur Info: Diese ECC DRAM sind völlig kompatibel zu konventionellen Speicherchips, führen aber selbstständig den ECC Algorithmus aus (erstellen selbst die Prüfbits, legen diese selbst in einem extra Bereich ab, prüfen und korrigieren vor der Ausgabe der Daten). Durch diese völlig Kompatibilität zu gewöhnlichen DRAMs ist es damit erstmals möglich, jedes Gerät, welches DRAM-Speicher einsetzt, einfach durch Austausch der Chips mit einer Fehlerkorrektur auszustatten, ohne dass spezielle ECC-fähige CPUs oder Chipsets benötigt werden. Man könnte damit zum Beispiel auch WLAN-Router, den Cache/Buffer auf Festplatten und SSDs, kleinformatige Industriecomputer und jedes andere Gerät mit ECC ausstatten, da man nicht mehr "72 Bit breiten Speicher" (= viele Chips bzw große Module und teure Prozessoren) benötigt.

Auch interessant für die Leser (gerade weil Row Hammer sich ja meist auf Computer bezieht): Diese selbstkorrigierenden ECC Speicherchips sind auch auf normalen 64 Bit breiten Speichermodulen erhältlich, die sich dann "intECC Speichermodule" nennen, also mit integrierter Fehlerkorrektur, weil sie aus selbstkorrigierenden ECC DRAM Chips gebaut sind. Diese Module sind bisher noch nicht auf der Herstellerwebseite von Intelligent Memory zu finden. Ich habe aber Bilder sowohl von den ECC Chips als auch von den "intECC Speichermodulen" hier vorliegen, weil ich bei einem Distributor arbeite, der die Dinger führt.

Jetzt soll das Ganze natürlich keine Werbung für Intelligent Memory werden, aber zumindest sollte der oben genannte Fehler korrigiert und die neue Technologie der ECC DRAMs und intECC Module erwähnt werden.

Da es beim deutschen Wikipedia noch keinen Eintrag über ECC gibt, könnte man zusätzlich auch einen neuen Eintrag machen, der generell ECC in Elektronikanwendungen erklärt. Es gibt bisher im Wikipedia nur "Fehlerkorrekturverfahren" zu denen untergeordnet ECC zählt. Die User suchen aber tatsächlich eher den Begriff "ECC Error-Correcting Code", der meiner Meinung nach einen eigenen Eintrag verdient, unabhängig vom allgemeinen Begriff der Fehlerkorrekturverfahren. Twmemphis (Diskussion) 13:32, 26. Mär. 2015 (CET)

Laut Yoongu et al [1] (Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors) stimmt das mit dem ECC als Abwehrmaßnahme nicht. Zitat aus dem Paper Seite 8: " This has an important consequence for error-correction codes (ECC). For example, SECDED (single error-correction, double error- detection) can correct only a single-bit error within a 64-bit word. If a word contains two victims, however, SECDED cannot correct the resulting double-bit error. And for three or more victims, SECDED cannot even detect the multi-bit er- ror, leading to silent data corruption. Therefore, we conclude that SECDED is not failsafe against disturbance errors." Somit gibt es keine wissenschaftlich fundierte analyse die die Aussage ECC schützt vor bitflips stützt. Übrigens beim Rowhammering das vom Project Zero betrieben wurde werden diverse Bits gekippt. (nicht signierter Beitrag von 93.232.29.125 (Diskussion) 18:08, 11. Jun. 2015 (CEST))

Fehlende Quelle=

Es fehlt die Quelle für die Aussage das der Angriff seit 2003 bekannt war. Soweit ich mich erinnere ist das Paper von Yoongu neueren Datums. Kann also nicht die Quelle sein. (nicht signierter Beitrag von 93.232.24.184 (Diskussion) 11:08, 30. Aug. 2015 (CEST))

Ich weiß nicht, ob du meine Antwort dir noch durchlesen wirst (ich hoffe es jedenfalls), jedenfalls habe ich die Aussage, dass der Angriff bereits seit 2003 bekannt ist, dem Artikel von Mirko Lindner bei pro-linux.de entnommen. --Speedpera (Diskussion) 21:27, 21. Jan. 2016 (CET)

Widersprüchliche Aussagen?

"Seitens Seaborn werden zur Zeit weitere Angriffe ohne Clflush diskutiert, praktisch umgesetzt wurde davon jedoch keiner." vs. "Im Juli 2015 gelang es Gruss, Maurice und Mangard über JavaScript den Rowhammer-Effekt auszulösen. Der Angriff basiert nicht darauf spezielle JavaScript-Funktionen auszunutzen, sondern darauf den Clflush-Befehl durch gezielte Speicherzugriffe zu simulieren." --Maxiantor (Diskussion) 09:26, 17. Mär. 2016 (CET)