Paul Stanik
Veteran
- Mitglied seit
- Nov 29, 2018
- Beiträge
- 227
- Bewertungspunkte
- 33
- Punkte
- 27
News Nach dem Windows-Retpoline-Update sorgt ein Sicherheitsteufel erneut für Besorgnis
- Themenstarter Paul Stanik
- Beginndatum
Seskahin
Veteran
Bin hier auch etwas verwirrt von den Beiträgen. Wenn es ein Designfehler vom RAM ist, warum sollte dies nicht auch für Ryzen gelten? Tut es in dem Fall aber nicht. Warum kann keiner sagen, nur das Intel keine Schuld hat.... Das ist mir echt zu dünn. Entweder liegt es an der CPU oder dem Chipsatz. Beides kommt bei Intel von Intel, also haben die es auch verbockt. Man hätte es anscheinend ja auch besser machen können, wenn einem Sicherheit wichtig wäre im Design.
FfFCMAD
Urgestein
Rowhammer ist ein Fehler des RAMs. Die Strukturen sind so klein, das man mit Schreib/ Lesezugriffen benachbarte Zellen kippen lassen kann. Das hat -fast- nichts mit der CPU und dem Chipset/ Speichercontroller zu tun. Nur: Je schneller diese Komponenten sind, umso mehr Bits koennen gekippt werden. Der Hersteller der Komponenten ist voellig egal. Intel hat nur den Errata verbockt. Die Sicherheitsluecke hat jedoch jeder im PC, der mindestens DDR3 in seinem Rechner verbaut hat. Bei DDR2 ist das Gelingen noch sehr unwahrscheinlich bis ausgeschlossen (Vielleicht sind bei besseren Herstellungsverfahren die letzten Module betroffen, ist aber blanke Theorie)
Das du, bei dem Dokument was Derf netterweise gepostet hat, siehst, das der AMD weiter unten bei den gekippten Bits anfaengt, kannst du der Performance der CPU und der Datenrate im RAM zuordnen. Das wird dort sogar geschrieben. Der Intel pumpte in dem Fall einfach mehr durch den Riegel. Neuere AMD CPUs sind auch zu hohen Durchsaetzen in der Lage. Und auch andere Architekturen werden Bits kippen, sobald sie den RAM ausreizen.
Eigentlich kann man ueber das Errata nur herausfinden, wo man mit Rowhammer ansetzen kann. Ich korrigiere das hier mal. (Habe es mir noch mal an anderer Stelle durchgelesen. In dem Fall gibt es nicht so wie bei Spectre eine Softwarebremse) Das der Angriff per Rowhammer klappt, ist alleine dem defekten RAM verschuldet.
Und ja, der RAM ist dysfunktional. Er kann innerhalb der angegebenen Spezifikationen seine Daten nicht mal im Ansatz ohne Gefahr der Korruption halten. Das ist ja nicht nur ein Bit die Woche oder so, das sind, wie im Dokument angezeigt, mehrere Megabyte die Sekunde, die da kippen. Das ist ein fatales Versagen.
Und das klappt mit Ryzen genauso gut. Nur das der in der von Intels Errata betroffenen Situation eben heil davon kommt, weil da das Errata nicht funktioniert. Beim Ryzen wuesste der Angreifer nicht, wo er Rowhammer abwerfen muss. Zum Stillstand/ Absturz/ Korruption des Systems reicht es jedoch allemal.
Edit! (Fehlerkorrektur)
Das du, bei dem Dokument was Derf netterweise gepostet hat, siehst, das der AMD weiter unten bei den gekippten Bits anfaengt, kannst du der Performance der CPU und der Datenrate im RAM zuordnen. Das wird dort sogar geschrieben. Der Intel pumpte in dem Fall einfach mehr durch den Riegel. Neuere AMD CPUs sind auch zu hohen Durchsaetzen in der Lage. Und auch andere Architekturen werden Bits kippen, sobald sie den RAM ausreizen.
Eigentlich kann man ueber das Errata nur herausfinden, wo man mit Rowhammer ansetzen kann. Ich korrigiere das hier mal. (Habe es mir noch mal an anderer Stelle durchgelesen. In dem Fall gibt es nicht so wie bei Spectre eine Softwarebremse) Das der Angriff per Rowhammer klappt, ist alleine dem defekten RAM verschuldet.
Und ja, der RAM ist dysfunktional. Er kann innerhalb der angegebenen Spezifikationen seine Daten nicht mal im Ansatz ohne Gefahr der Korruption halten. Das ist ja nicht nur ein Bit die Woche oder so, das sind, wie im Dokument angezeigt, mehrere Megabyte die Sekunde, die da kippen. Das ist ein fatales Versagen.
Und das klappt mit Ryzen genauso gut. Nur das der in der von Intels Errata betroffenen Situation eben heil davon kommt, weil da das Errata nicht funktioniert. Beim Ryzen wuesste der Angreifer nicht, wo er Rowhammer abwerfen muss. Zum Stillstand/ Absturz/ Korruption des Systems reicht es jedoch allemal.
Edit! (Fehlerkorrektur)
Zuletzt bearbeitet
:
Derfnam
Urgestein
- Mitglied seit
- Jul 22, 2018
- Beiträge
- 7.517
- Bewertungspunkte
- 2.029
- Punkte
- 114
Ne weitere Suche ergab übrigens, dass auch ECC-RAM nicht davor gefeit ist. Und das alles ist auch auf Mobiltelefonen reproduzierbar. Imho dürfte eher die JEDEC-Organisation den schwarzen Peter haben.
Die Sache ist gar nicht so kompliziert.
Kein mir bekannter RAM arbeitet fehlerfrei. Je schneller der RAM ist, desto höher ist die Chance, einen Fehler innerhalb einer bestimmten Zeit zu erhalten. Rowhammer nutzt diese Tatsache aus. Bisher waren die Angriffe aus meiner Sicht nicht praxistauglich. Das hat sich aus meiner Sicht bei den Intel-Core-CPUs mit Entdeckung dieses Fehlers geändert.
Ich finde es allerdings etwas kurzsichtig, das Problem nur beim RAM zu sehen. Mir ist derzeit kein Speicher bekannt, der immer fehlerfrei arbeitet.
Kein mir bekannter RAM arbeitet fehlerfrei. Je schneller der RAM ist, desto höher ist die Chance, einen Fehler innerhalb einer bestimmten Zeit zu erhalten. Rowhammer nutzt diese Tatsache aus. Bisher waren die Angriffe aus meiner Sicht nicht praxistauglich. Das hat sich aus meiner Sicht bei den Intel-Core-CPUs mit Entdeckung dieses Fehlers geändert.
Ich finde es allerdings etwas kurzsichtig, das Problem nur beim RAM zu sehen. Mir ist derzeit kein Speicher bekannt, der immer fehlerfrei arbeitet.
FfFCMAD
Urgestein
Ja. Das mal ein kippendes Bit auftritt, ist ja auch entsprechend bei den Speicherbausteinen spezifiziert. Dummerweise findet man dazu meist nichts in den Spezifikationen der Module. Macht sich nicht gut im Verkauf. Kippendes Bit im RAM ist halt nicht verkaufsfaehig. Aus gutem Grund. Und selbst wenn du ein kippendes Bit/h spezifizierst, bist du damit noch in Form von Galaxien von der Rowhammer-Methode entfernt. Da kannst du ein brauchbares 4K HDR-Video mit Dolby Atmos mit der Menge an Daten streamen, welche hier ueber den Jordan gehen. Und mit dem Phenom reichts noch fuer ein Full-HD Video.
Der RAM, wenn innerhalb seiner Spezifikationen/ Timings usw. betrieben, muss das aushalten. Wenn nicht, ist er als unbrauchbar/ defekt anzusehen. Punkt. Wie Derf schon sagt, sehe ich hier auch Jedec am Hebel. Habe ich schon im anderen Thread geschrieben.
https://www.intelligentmemory.com/s...cur-and-how-about-double-multi-bit-errors.php
Der RAM, wenn innerhalb seiner Spezifikationen/ Timings usw. betrieben, muss das aushalten. Wenn nicht, ist er als unbrauchbar/ defekt anzusehen. Punkt. Wie Derf schon sagt, sehe ich hier auch Jedec am Hebel. Habe ich schon im anderen Thread geschrieben.
https://www.intelligentmemory.com/s...cur-and-how-about-double-multi-bit-errors.php
Also mal kurzerhand sämtlichen RAM als defekt zu anzusehen ist schon ein bisschen extrem hart. Ich würde nicht so weit gehen, da es hier um etwas geht, was aus meiner Sicht physikalisch, bei immer kompakteren Strukturgrößen und immer höheren Takt, kaum zu vermeiden ist. Soweit ich weiß könnte die Rowhammermethode theoretisch sogar beim CPU-Cache funktionieren, wenn dieser nicht ständig neu beschrieben würde.
FfFCMAD
Urgestein
CPU-Cache besteht normalerweise aus SRAM und verfuegt fast immer ueber ECC. Auch sind die Strukturen viel groeßer/ die Funktionsweise komplett anders, deswegen ist SRAM so teuer. Auch werden die Zellen nicht unbedingt gestapelt usw. Bzw. noch nicht.
Und ja, wenn der RAM innerhalb seiner Spezifikationen nicht funktioniert, ist er defekt. Bzw handelt es sich hier um einen Designfehler, der mit DDR5 hoffentlich aus der Welt verschwindet. Erwarten brauchen wir das jedoch nicht. Weil das die Hersteller bei den RAM-Kapazitaeten zurueckwerfen wuerde und auch die Kosten steigen. Das klingt zwar krass, ist aber eben eine logische Schlussfolgerung. Der RAM ab DDR3 ist nicht mehr in der Lage, die Daten unter Vollast bei normalen Betriebsbedingungen stabil zu halten. Also entweder dreht man den refresh so hoch, das die Zellen aufgefrischt werden, bevor Rowhammer ueberhaupt greifen kann. Oder man baut DDR5 komplett neu. Ersteres fuehrt zu Performanceeinbussen. Wenn man das als Kunde so kauft, ist das wohl auch Ok. Aktuell wird RAM aber eben dysfunktional verkauft. Weils die Nutzer nicht merken.
Und Rowhammer erzeugt keinen ungewoehnlichen Load in dem Sinne. erlaubt ist alles, was der RAM mit seinen Timings zulaesst. Dafuer sind die Timings da. Ist schließlich ein passives Element.
Und ja, wenn der RAM innerhalb seiner Spezifikationen nicht funktioniert, ist er defekt. Bzw handelt es sich hier um einen Designfehler, der mit DDR5 hoffentlich aus der Welt verschwindet. Erwarten brauchen wir das jedoch nicht. Weil das die Hersteller bei den RAM-Kapazitaeten zurueckwerfen wuerde und auch die Kosten steigen. Das klingt zwar krass, ist aber eben eine logische Schlussfolgerung. Der RAM ab DDR3 ist nicht mehr in der Lage, die Daten unter Vollast bei normalen Betriebsbedingungen stabil zu halten. Also entweder dreht man den refresh so hoch, das die Zellen aufgefrischt werden, bevor Rowhammer ueberhaupt greifen kann. Oder man baut DDR5 komplett neu. Ersteres fuehrt zu Performanceeinbussen. Wenn man das als Kunde so kauft, ist das wohl auch Ok. Aktuell wird RAM aber eben dysfunktional verkauft. Weils die Nutzer nicht merken.
Und Rowhammer erzeugt keinen ungewoehnlichen Load in dem Sinne. erlaubt ist alles, was der RAM mit seinen Timings zulaesst. Dafuer sind die Timings da. Ist schließlich ein passives Element.
FfFCMAD
Urgestein
Ja. Aber bei SRAM ist es so oder so bereits schwieriger. Zum einen kannst du den Cache der CPUs nur indirekt steuern. (Die selben Zellen gezielt zu lesen und zu beschreiben ist "ziemlich" ausgeschlossen) Zum Anderen greift hier eben auch noch ECC oben drauf. Da muessten schon mindestens 2 Bits kippen... Die Dichte und die Schaltung von SRAM ist eine komplett andere als DRAM. Rowhammer koennte in der Theorie mit SRAM funktionieren. Aber so, wie SRAM implementiert und genutzt wird >> Da gibts andere Macken die auszunutzen waeren. Zum Beispiel das jedes Cachelevel der CPU eine Kopie aus des jeweils hoeheren Level entaehlt etc 
Das Rowhammer mit den Chache der CPU funktioniert >> So eher nicht. Auch wenn man es nicht zu 100% ausschließen kann.
Das Rowhammer mit den Chache der CPU funktioniert >> So eher nicht. Auch wenn man es nicht zu 100% ausschließen kann.
FfFCMAD
Urgestein
Achso: Bei LPDDR4 scheint Jedec bereits ein Timings spezifiziert zu haben, welches Rowhammer erschweren/ verhindern soll. TRR oder so.
Eine andere Loesung koennte sein, einen intelligenten Cache zusaetzlich zum RAM an den Speichercontroller zu haengen. Welcher Schreib/ Lesezugriffe intelligent puffert und erkennt, ob eine Bank oft geaendert wird. Das ksotet natuerlich viel Geld. Wuerde ich aber besser finden, als diesen RGB-Blingmist. Und wuerde die Performance des RAM, speziell bei Dual-Channellattformen mit 8/ 16Kern-CPUs, wie sie bald auftauchen werden, auf die Spruenge helfen. Dafuer muesste der Cache aber recht groß sein. Und der Speichercontroller + SRAM waere teuer. Im Zusammenspiel mit dem TRR-Timing waere das aber eine zukunfstfaehigere Loesung.
Eine andere Loesung koennte sein, einen intelligenten Cache zusaetzlich zum RAM an den Speichercontroller zu haengen. Welcher Schreib/ Lesezugriffe intelligent puffert und erkennt, ob eine Bank oft geaendert wird. Das ksotet natuerlich viel Geld. Wuerde ich aber besser finden, als diesen RGB-Blingmist. Und wuerde die Performance des RAM, speziell bei Dual-Channellattformen mit 8/ 16Kern-CPUs, wie sie bald auftauchen werden, auf die Spruenge helfen. Dafuer muesste der Cache aber recht groß sein. Und der Speichercontroller + SRAM waere teuer. Im Zusammenspiel mit dem TRR-Timing waere das aber eine zukunfstfaehigere Loesung.
Den zusätzlichen Cache betrachte ich als die vernünftigere Lösung. Von der Variante mit den Timings halte ich persönlich nicht viel.
Was den Cache angeht: Ich hatte nicht umsonst theoretisch gesagt. Praktisch dürfte es aus meiner Sicht wohl fast unmöglich sein, da der Cacheinhalt normalerweise viel zu oft geändert wird. Es sollte nur als Beispiel dienen.
Selbstnotiz für mich: Keine Beispiele mehr
Was den Cache angeht: Ich hatte nicht umsonst theoretisch gesagt. Praktisch dürfte es aus meiner Sicht wohl fast unmöglich sein, da der Cacheinhalt normalerweise viel zu oft geändert wird. Es sollte nur als Beispiel dienen.
Selbstnotiz für mich: Keine Beispiele mehr