Forum: PC Hard- und Software Rowhammer-Attacke


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Heise Security beschreibt eine interessante Attacke (nicht nur) auf 
Linux-Systeme: die Rowhammer-Attacke.

http://www.heise.de/security/meldung/Rowhammer-RAM-Manipulationen-mit-dem-Vorschlaghammer-2571835.html

Dazu werden Speicherzellen ausgelesen, die neben sicherheitsrelevanten 
Zellen liegen. Durch das Auslesen sollen sich Bits in den Nachbarzellen 
ändern können und so eine Rechte-Eskalation ermöglichen.

Alles ziemlich dubios... Aber eine Frage stellt sich: wie kann es 
passieren, dass durch Auslesen einer RAM-Zelle Inhalte von Nachbarzellen 
verändert werden?

Bis zum 1. April ist es doch noch eine Weile...


Nachtrag: Das ist ja fast so wüst, wie die Geschichte von den Rechnern 
aus den 1960ern, deren Kernspeicher man braten konnte, indem man eine 
unendliche Schleife der Bauart
jmp $

programmierte. Dabei rauchten die Speicherkerne ab, in denen der Befehl 
gespeichert war.

: Bearbeitet durch User
von gg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie im Artikel schon steht - bei den sehr kleinen modernen Strukturen 
liegen die Zellen sehr dicht beisammen und könnten sich beeinflussen.
Könnte dann sein, dass beim Auslesen da "übersprechen" auftritt.
Das sind ja nur winzige Kondensatoren... die auch noch regelmäßig 
aufgefrischt werden wollen weil sonst die Daten verloren gehen.


Mit ECC Speicher klappt das nicht, weil der einzelne Bitfehler erkennen 
und korrigieren kann.
Also Lösung: nächsten Rechner mit ECC Speicher bauen ;-)

von Icke ®. (49636b65)


Bewertung
-1 lesenswert
nicht lesenswert
Wahrscheinlich sind im Rechner des Redakteurs ein paar Bits gekippt und 
haben das Datum auf den 1.4. geändert.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Ich behaupte jetzt einfach mal, dass RAM-Bausteine, bei denen sowas 
möglich ist, Ausschuss sind. Sowas sollte eigentlich mit kritischen 
Zugriffsmustern beim Test auffallen - sofern überhaupt getestet wird und 
nicht einfach Banana-Hardware verscherbelt wird.

von A. H. (ah8)


Bewertung
0 lesenswert
nicht lesenswert
Es dürfte relativ leicht sein heraus zu finden, auf welchen Adressen der 
Kernel sensible Daten speichert. Dann muss ich aber wissen, welche Chips 
verbaut sind um Zellen zu finden, die direkt daneben liegen und dann 
muss ich die Speicherverwaltung überzeugen, mir die Seite zuzuweisen, 
die genau diese Zellen enthält. Ich kann ja als User nur auf virtuelle 
Adressen zugreifen und mir ist gerade keine Möglichkeit bekannt heraus 
zu finden, welche physischen Adressen eigentlich dahinter liegen. (Ich 
hatte allerdings auch noch nie einen Grund, das wissen zu wollen :-)

Vielleicht kann man ja auch durch das Einrammen von Pfählen vor einer 
Bank das Gebäude so in Vibrationen versetzen, dass sich die Schlösser 
einiger Tresore von allein öffnen. Ob das dann aber eine praktikabler 
Weg für einen Bankraub wäre wage ich zu bezweifeln.

von Uhu U. (uhu)


Bewertung
1 lesenswert
nicht lesenswert
A. H. schrieb:
> Ob das dann aber eine praktikabler Weg für einen Bankraub wäre wage
> ich zu bezweifeln.

Die Möglichkeit, sowas zu einer Attacke auszunutzen beunruhigt mich 
weniger, als die, dass aus derlei Verhalten des RAMs Systeminstabilität 
resultiert.

von Arduinoquäler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
gg schrieb:
> Wie im Artikel schon steht - bei den sehr kleinen modernen Strukturen
> liegen die Zellen sehr dicht beisammen und könnten sich beeinflussen.
> Könnte dann sein, dass beim Auslesen da "übersprechen" auftritt.

Das passiert täglich auf Millionen von Rechnern ohne weiteres
böses Zutun.

Und was passiert also Folge davon? Nichts. Jedenfalls kein
"Übersprechen".

Toll mit was für Käse manche Menschen ihre Lebenszeit vergeuden.

von A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Arduinoquäler schrieb:
> Toll mit was für Käse manche Menschen ihre Lebenszeit vergeuden.

Mir wärs auch lieber, wenn sich weltweit niemand mit solchem Käse 
befassen müsste...

"Den IT-Sicherheitsforschern Mark Seaborn, Matthew Dempsky und Thomas 
Dullien ist es gelungen, durch permanente Speicherzugriffe ausgelöste 
Bitflips auszunutzen, um aus einer Sandbox auszubrechen und auf einem 
Linux-System Root zu werden." [Golem]

Details: 
http://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

Wärs ein paar Wochen später würde ich das auch als Aprilscherz abtun. 
Und ich hoffe immer noch inständig, dass da jemand auf dem Kalender 
verrutscht ist. Aber es sieht doch ein bisserl zu ernsthaft aus.

: Bearbeitet durch User
von Icke ®. (49636b65)


Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> Wärs ein paar Wochen später würde ich das auch als Aprilscherz abtun.

Genauso wie Schololadenweihnachtsmänner und -osterhasen lange vor den 
entsprechenden Anlässen in den Regalen liegen, kommen auch die 
Aprilscherze immer früher. Jeder Hoaxer will der Erste sein. Unbenommen 
der Tatsache, daß es kein einziges System geben dürfte, daß länger als 
ein paar Minuten stabil läuft, wenn benachbarte Zugriffe Bits kippen 
ließen, scheitert eine solche Attacke auch daran, daß Speicherriegel in 
unterschiedlichsten Organisationen verbaut vorkommen und somit gar nicht 
gezielt nebeneinander liegende Zellen getroffen werden können. Und dann 
gibt es noch den CPU-Cache...

von Arduinoquäler (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
A. K. schrieb:
> Aber es sieht doch ein bisserl zu ernsthaft aus.

Der Funken Wahrheit (oder a bisserl mehr) mag ja drin stecken.
Aber für die volle Breite der PCs ist das ohne Belang.

von A. H. (ah8)


Bewertung
1 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Die Möglichkeit, sowas zu einer Attacke auszunutzen beunruhigt mich
> weniger, als die, dass aus derlei Verhalten des RAMs Systeminstabilität
> resultiert.

Das stimmt. Allerdings kann man die Welt nicht beliebig sicher machen. 
Wir hatten mal einen Praktikanten, der sollte ein Rack aus dem 
Rechenzentrum schieben, hatte aber dummerweise die Tür nicht getroffen 
sondern fuhr rechts neben der Tür gegen die Wand. Dort war der 
Not-Aus-Schalter. Für's ganze Rechenzentrum. Wir hatten viel Spaß den 
Rest des Tages.

von Uhu U. (uhu)


Bewertung
1 lesenswert
nicht lesenswert
A. H. schrieb:
> Allerdings kann man die Welt nicht beliebig sicher machen.

Darum gehts auch nicht. Sporadische Systemabstürze, deren Ursache nicht 
feststellbar sind, sind so ziemlich das Schlimmste, was ich auf diesem 
Sektor kenne.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Und dann gibt es noch den CPU-Cache...

Mindestens hättest du es mal überfliegen können. ;-)
Daran wurde selbstredend gedacht.

von Andreas S. (andreas) (Admin) Benutzerseite Flattr this


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> ...

Lies doch einfach mal den von A.K. verlinkten Artikel, er beantwortet 
alle deine Fragen.

von Dennis R. (dennis_r93)


Bewertung
1 lesenswert
nicht lesenswert
Der Angriff macht Sinn.

Die FETs und die Wortleitung in der Speicherbank haben Kapazitäten -> es 
fliest ein Strom.
Dadurch wird in die benachbarte Leitung eine Spannung eingestreut, die 
Gates der benachbarten Leitung werden minimal leitfähig und ein teil der 
Ladung geht auf die Wortleitung verloren.


>> daß es kein einziges System geben dürfte, daß länger als
>> ein paar Minuten stabil läuft, wenn benachbarte Zugriffe Bits kippen
>> ließen

Das liegt daran, dass der Ladungsverlust nur minimal ist. es braucht ca. 
138.000* Zugriffe bis einzelne benachbarte Bit's fallen.
und die Zugriffe müssen auch noch zwischen 2 Auffrischungszyklen liegen

*Wenn ich mich richtig erinnere

von Icke ®. (49636b65)


Bewertung
-2 lesenswert
nicht lesenswert
A. K. schrieb:

> Daran wurde selbstredend gedacht.

Dann fällt der Punkt halt weg, das ändert aber nichts am Hoax. Nicht 
umsonst gibt es definierte Latenzzeiten für Speicherzugriffe. Ist ein 
System spezifikationsgemäß konfiguriert, dann sorgt der 
Refreshmechanismus zuverlässig dafür, daß sich ausgelesene Zellen wieder 
so weit erholen, daß keine Kipper auftreten. Auch wenn sie bis zum 
jüngsten Tag gelesen werden (falls die Hardware bis dahin überlebt).

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Dennis R. schrieb:
> und die Zugriffe müssen auch noch zwischen 2 Auffrischungszyklen liegen

Der Sinn der Latencys ist ja gerade, dies zu verhindern. Man müßte schon 
das BIOS manipulieren, wozu mindestens Rootrechte notwendig sind. Wenn 
man die schon hat, kann man sich die Attacke aber sparen.

von Uhu U. (uhu)


Bewertung
2 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Dann fällt der Punkt halt weg, das ändert aber nichts am Hoax.

Hoax? Nein, das ist ein prinzipielles Problem, das für kleine µC-Systeme 
- ohne Cache - üble Folgen haben kann.

> Ist ein System spezifikationsgemäß konfiguriert, dann sorgt der
> Refreshmechanismus zuverlässig dafür, daß sich ausgelesene Zellen wieder
> so weit erholen, daß keine Kipper auftreten.

Wenn dennis_r93 mit den 138.000 Lesezugriffen richtig liegt, dann 
müssten 64 ms Refresh viel zu viel sein - ob der Wert über den 
Spezifikationen liegt? Kaum.

Icke ®. schrieb:
> Wenn man die schon hat, kann man sich die Attacke aber sparen.

Die Attacke ist uninteressant. Interessant sind die Instabilitäten, die 
evtl. ungewollt auftreten und auf das Problem zurück gehen.

: Bearbeitet durch User
von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Der Sinn der Latencys ist ja gerade, dies zu verhindern.

Das Refresh-Intervall einer Speicherzelle (d.h. einer Row) liegt im 
Millisekundenbereich. Mir wärs schon lieber, wenn auf man deren 
Nachbar-Rows nicht nur alle paar Millisekunden zugreifen dürfte, denn 
dann hätten wir beim Trommel-Hauptspeicher der IBM 650 bleiben können.

Der einzige Sinn von Latencies besteht ausserdem darin, so kurz wie 
technisch möglich sein. ;-)

: Bearbeitet durch User
von Icke ®. (49636b65)


Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> Das Refresh-Intervall einer Speicherzelle (d.h. einer Row) liegt im
> Millisekundenbereich.

Gut, das stimmt. Trotzdem sind die Hardwaredesigner nicht dúmm. Es würde 
mich schon sehr wundern, wenn wiederholte Zugriffe nicht eingeplant 
wären, noch dazu bei der relativ läppischen Zahl von 138000. Außerdem 
könnte man mit der Methode das Kippen nur in eine Richtung bewirken, was 
das Erzeugen funktionierenden Codes nochmals erschwert.

Uhu Uhuhu schrieb:
> Nein, das ist ein prinzipielles Problem, das für kleine µC-Systeme
> - ohne Cache - üble Folgen haben kann.

Die "kleinen" µCs arbeiten i.d.R. mit SRAM, wären also gar nicht 
betroffen. Aber vielleicht kann mal ein Cortex-Programmierer 
Beispielcode für ein System mit externem DRAM schreiben, um die These zu 
verifizieren.

von A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Gut, das stimmt. Trotzdem sind die Hardwaredesigner nicht dúmm.

Die Entwickler von OpenSSL sich auch nicht dumm. Ich nehme an, dass 
sogar die Entwickler von Adobe nicht dumm sind, auch wenn ich mich mit 
dieser Annahme vielleicht unbeliebt mache. ;-)

Trotzdem gibts überall Probleme, wo immer du hinsiehst. Auch in 
Hardware. PC/Server-Prozessoren haben eine ziemlich dicke Liste mit 
Problemen, und da sind auch ein Haufen effektiv nichtdeterministische 
Probleme drin. Intel musste in den Haswells nachträglich per BIOS-Update 
genau jene Feature abschalten, die deren grosser struktureller Vorteil 
gegenüber der Vorgängergeneration war (ok, anfangs nutzt die sowieso 
fast niemand, eben weil zu neu).

Schon vor Jahren stellte man fest, dass man Verschlüsselungsprogramme 
knacken kann, indem man das Zeitverhalten eines Fremdprozesses über 
gezielte Nutzung des Verdrängungsverhaltens von Caches und TLBs 
manipuliert, und so auf dessen Speicherzugriffe schliessen kann.

Nein, man kann nicht an alles denken. Aber man weiss nachher immer, dass 
man vorher an diese dumme Sache eigentlich hätte denken sollen.

: Bearbeitet durch User
von gg (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Trotzdem sind die Hardwaredesigner nicht dúmm.

Schau Dir mal die Erratas zu modernen Mikrocontrollern / SoCs an.
Das ist oft ein zweites "Datenblatt" von der Länge her...
(kommt von der ständig wachsenden Komplexität. Es soll aber trotzdem 
alles immer schneller und billiger entwickelt werden - da bleibt wenig 
Zeit zum Testen)

von Icke ®. (49636b65)


Bewertung
-4 lesenswert
nicht lesenswert
A. K. schrieb:
> Die Entwickler von OpenSSL sich auch nicht dumm.

Nee, nur grob fahrlässig. Wenn man den Heartbleed-Bug betrachtet, muß 
vielleicht sogar Vorsatz unterstellt werden.

> und da sind auch ein Haufen effektiv nichtdeterministische
> Probleme drin.

Die theoretische (und praktische) Möglichkeit, daß ein Programm 
wiederholt auf eine Speicherzelle zugreift, zählt m.E. zu den leicht 
vorhersehbaren Problemen.

Wie auch immer, wir sprechen uns im April wieder...

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Wie auch immer, wir sprechen uns im April wieder...

Ich hoffe es sehr. Nur wundert mich mittlerweile in dieser Beziehung 
kaum noch etwas. Die Nach-Snowden Ära hat Verschwörungstheorien ja auch 
eine gänzlich neue Bedeutung verpasst.

von Icke ®. (49636b65)


Bewertung
1 lesenswert
nicht lesenswert
A. K. schrieb:
> Ich hoffe es sehr.

Ich auch, ansonsten fall ich vom Glauben ab, mach meinen IT-Laden zu und 
laß mich zum Friedhofsgärtner umschulen...

von Abdul K. (ehydra) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Refresh, klingt schon seltsam! Vor Äonen habe ich bei meinen 64KBit 
DRAMs den Refresh abgeschaltet und andere Spielereien probiert. Manche 
Bereiche hatten noch nach Sekunden die Daten frisch.
Was ich mir vorstellen könnte, wäre ein fehlerhaftes Design. Bei dem bei 
zu häufigen Zugriffen in gleiche Bereiche die Refresh-Logik irgendwann 
blockiert wird.

Auf dem Friedhof ist alle 20 Jahre Refresh ;-)

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Abdul K. schrieb:
> Refresh, klingt schon seltsam!

Die beschriebene Methode hat mit dem Refresh praktisch nichts zu tun. 
Wenn über wiederholte Zugriffe die Ladung einer Nachbarzelle sukzessive 
beeinflusst werden kann, dann muss das allerdings vor dem nächsten 
Refresh (oder Lesezugriff) dieser Zelle zu Potte kommen, sonst war die 
Mühe umsonst.

: Bearbeitet durch User
von Abdul K. (ehydra) Benutzerseite


Bewertung
-3 lesenswert
nicht lesenswert
Ich kann mir da keine Allgemeingültigkeit vorstellen. Wenn, dann ist da 
ein fehlerhaftes Design schuld. Was dann den Kreis der betroffenen 
Systeme einschränkt. Gut, der Kreis kann groß sein bei der heutigen 
Oligopolie der wenigen Hersteller.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Abdul K. schrieb:
> Ich kann mir da keine Allgemeingültigkeit vorstellen.

Angesichts der Vielzahl real existierender Hersteller von DRAM-Chips 
braucht man eine Allgemeingültigkeit wohl auch nicht. ;-)

Wieviel sind es denn? Samsung, Hynix, Micron ... fehlt wer? Wenn es 
Samsung betreffen sollte, dann wäre doch schon der halbe Markt dabei.

: Bearbeitet durch User
von Ich (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Der Vollständigkeit halber, der etwas akademischer gehaltene 
ursprüngliche Artikel: 
http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf

"We demonstrate this phenomenon on Intel and AMD systems using a 
malicious program that generates many DRAM accesses. We induce errors in 
most DRAM modules (110 out of 129) from three major DRAM manufacturers. 
From this we conclude that many deployed systems are likely to be at 
risk."

von Florian H. (heeen)


Bewertung
0 lesenswert
nicht lesenswert
Fefe muss wohl mit diesen Hoaxern unter einer Decke stecken 
http://blog.fefe.de/?ts=aa00f778

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Florian H. schrieb:
> Fefe muss wohl mit diesen Hoaxern unter einer Decke stecken

Möglicherweise ist die Kiste auch nur infolge Überhitzung durch die 
stundenlange Dauerlast abgekackt.

Ich schrieb:
> Der Vollständigkeit halber, der etwas akademischer gehaltene
> ursprüngliche Artikel:
> http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf

Hab ich mir durchgelesen. Es läßt sich daraus schlußfolgern, daß 
bestimmte Systeme in der Tat anfällig für Bitfehler durch intensive 
Lesezugriffe sind. Es läßt sich aber NICHT schlußfolgern, daß mit der 
Methode GEZIELTE Bitmanipulationen möglich sind. Wildes Hämmern 
verursacht eher nur zufällig erwünschte Bitflips aber zusätzlich jede 
Menge Kollateralschaden. Meiner Meinung nach ist daher die 
Wahrscheinlichkeit, das System zum Absturz zu bringen, um 
Größenordnungen höher als Rootrechte zu erlangen, und daraus noch Nutzen 
zu ziehen.

Ich bin kein Systemprogrammierer, könnte mit aber durchaus wirksame 
Gegenmaßnahmen auf OS-Ebene vorstellen. Zum einen nicht privilegierten 
Prozessen den Lesezugriff auf sensible Bereiche verwehren. Zum anderen 
diese Bereiche redundant an verschiedenen Stellen im Speicher halten und 
zusätzlich mit Prüfsummen/CRC plausibilisieren. Also wie das z.B. bei 
besseren Dateisystemen in ähnlicher Form auch gemacht wird. Desweiteren 
gibt es auf Hardwareseite die Möglichkeit, Refresh- und Zugriffstimings 
auf sichere Werte anzupassen, wenn auch mit einem gewissen 
Performanceverlust. Auf jeden Fall sehe ich in der Holzhammermethode 
keine besonders ernstzunehmende Gefahr.

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
> Es läßt sich aber NICHT schlußfolgern, daß mit der
> Methode GEZIELTE Bitmanipulationen möglich sind.

Nachdem das ein analoger Effekt ist, könnte das mit dem Arbeiten von 
zwei Seiten und bestimmten Bitpatterns her durchaus sein. Da kullern ja 
nur einige 100 Elektronen auf die Leitung, die vom Leseverstärker als 0 
oder 1 unterschieden werden müssen. Für bestimmte Speicherchiptypen wäre 
mit etwas Aufwand&Kosten ala NSA da evtl. schon was zu finden sein.

Trotzdem ist immer noch das Problem, dass man wissen muss, was "nebenan" 
eigentlich im Speicher liegt. Bei einem frisch gestarteten System wäre 
das sogar deutlich einfacher, weil es da noch kaum Seitenfragmentierung 
gibt. Da ist virtueller Speicher auch physikalisch hintereinander. Aber 
ein paar mal den Webbrowser gestartet und alles ist permutiert (BTDT).

> Zum einen nicht privilegierten Prozessen den Lesezugriff auf sensible
> Bereiche verwehren.

Du hast das Problem nicht ganz verstanden. Der Lesezugriff geht nur auf 
für den Prozess ganz normal zugreifbaren Addressen. Durch die virtuelle 
Speicherverwaltung können aber in 4k-Seiten "nebenan" OS-Teile liegen, 
die dadurch beeinflusst werden.

> Desweiteren  gibt es auf Hardwareseite die Möglichkeit, Refresh- und
> Zugriffstimings auf sichere Werte anzupassen,

Die normalen Zugriffstimings sind hier nutzlos, weil es die nur extern 
gibt. Intern läuft das Auslesen so schnell ab, wie es eben geht, es wird 
dann nur von den Daten her synchronisiert... Der Refresh wäre dem Paper 
nach wohl das einzige.

So inhaltlich klingt das ganz schon "technically sound", aber ein Hoax 
könnte es immer noch sein ;)

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Wildes Hämmern
> verursacht eher nur zufällig erwünschte Bitflips aber zusätzlich jede
> Menge Kollateralschaden. Meiner Meinung nach ist daher die
> Wahrscheinlichkeit, das System zum Absturz zu bringen, um
> Größenordnungen höher als Rootrechte zu erlangen, und daraus noch Nutzen
> zu ziehen.

Ach, hast dus jetzt auch gemerkt?

> Ich bin kein Systemprogrammierer, könnte mit aber durchaus wirksame
> Gegenmaßnahmen auf OS-Ebene vorstellen. Zum einen nicht privilegierten
> Prozessen den Lesezugriff auf sensible Bereiche verwehren.

Dann doch lieber ECC-RAM.

von X2 (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Memtest kann das mittlerweile auch ;-)

http://www.memtest86.com/support/ver_history.htm

New "Hammer Test" for detecting disturbance errors caused by charge 
leakage when repeatedly accessing addresses in the same memory bank but 
different rows in a short period of time.

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> Du hast das Problem nicht ganz verstanden. Der Lesezugriff geht nur auf
> für den Prozess ganz normal zugreifbaren Addressen. Durch die virtuelle
> Speicherverwaltung können aber in 4k-Seiten "nebenan" OS-Teile liegen,
> die dadurch beeinflusst werden.

Ich meine nicht den Zugriff zum Zwecke des Hämmerns, sondern in dieser 
Beziehung:

> Trotzdem ist immer noch das Problem, dass man wissen muss, was "nebenan"
> eigentlich im Speicher liegt.

Wozu benötigt ein Userprogramm bspw. Zugriff auf /proc/PID/pagemap und 
wozu muß es im Falle NaCl das Codesegment der Sandbox lesen können? Wenn 
das Userprog nur den ihm zugewiesenen Speicher lesen darf, kann es nicht 
prüfen, welche Erfolge die Klopforgie gezeitigt hat und die Attacke kann 
höchstens noch verwendnet werden, um den Rechner abzuschießen.

> Nachdem das ein analoger Effekt ist, könnte das mit dem Arbeiten von
> zwei Seiten und bestimmten Bitpatterns her durchaus sein.

Die Experten im o.g. Bericht haben es jedenfalls nicht geschafft. Selbst 
mehrere Durchläufe mit der gleichen Hardware brachten unterschiedliche 
Ergebnisse.

> So inhaltlich klingt das ganz schon "technically sound", aber ein Hoax
> könnte es immer noch sein ;)

Daß mit Rowhammer prinzipiell Bitflips erzeugt werden können, scheint zu 
stimmen. Aber aus der Methode einen verwertbaren Exploit zu 
konstruieren, dürfte ein Hoax sein.

von Icke ®. (49636b65)


Bewertung
-4 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Dann doch lieber ECC-RAM.

Oder ein sicheres Betriebssystem.

von Dufe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:

> Oder ein sicheres Betriebssystem.

Was soll ein OS an kaputten RAM ändern können?

von Christian B. (casandro) Flattr this


Bewertung
2 lesenswert
nicht lesenswert
Angriffe über Arbeitsspeicherfehler gibts schon lange. Da gab es auch 
mal Leute die ein radioaktives Präparat neben den Arbeitsspeicher 
gestellt haben um aus einer, damals als sicher geltenden, Java Sandbox 
auszubrechen.

Also was lernen wir daraus:
ECC-Ram ist ein Sicherheitsfeature
Auf Sandkästen kann man sich nicht verlassen

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Dufe schrieb:
> Was soll ein OS an kaputten RAM ändern können?

Wenig bis nichts. Es kann aber dafür sorgen, daß die Fehler nicht für 
Angriffe nutzbar sind, siehe oben.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Dufe schrieb:
>> Oder ein sicheres Betriebssystem.
>
> Was soll ein OS an kaputten RAM ändern können?

Kaputt vermeiden.

Per Hintergrundprozess mit vollem Tempo der Reihe nach alle Rows 
auslesen - ein Zugriff pro Row reicht. Ergibt einen Soft-Refresh mit 
sehr viel kürzerem Intervall als der Hardware-Refresh.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Per Hintergrundprozess mit vollem Tempo der Reihe nach alle Rows
> auslesen - ein Zugriff pro Row reicht. Ergibt einen Soft-Refresh mit
> sehr viel kürzerem Intervall als der Hardware-Refresh.

Und warum nicht gleich die Refreshrate erhöhen?

Generell sind Versuche, Hardwaremacken per Software auszuwetzen nicht 
effizient und tendieren dazu, ein Fass ohne Boden zu werden...

: Bearbeitet durch User
von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Und warum nicht gleich die Refreshrate erhöhen?

Oder das. Aber die Frage war nach dem Betriebssystem. ;-)

Ausserdem haben viele PCs noch haufenweise unausgelastete CPU-Kerne 
rumliegen. Warum nicht einmal etwas findet, das die auslastet?

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Warum nicht einmal etwas findet, das die auslastet?

Dann funktioniert die Kiste jedenfalls etwas besser als Heizung...

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Generell sind Versuche, Hardwaremacken per Software auszuwetzen nicht
> effizient und tendieren dazu, ein Fass ohne Boden zu werden...

Korrekt. Aber wie sonst will man den Leuten mit 8 CPU-Kernen einen neuen 
Prozessor mit 16 verkaufen? ;-)

von Martin S. (led_martin)


Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Generell sind Versuche, Hardwaremacken per Software auszuwetzen nicht
> effizient und tendieren dazu, ein Fass ohne Boden zu werden...

Leider ist das heute gängige Praxis, bei der unreifen 'Bananenware'. Die 
Hardware ist da oft genauso unreif, wie die Software. Software kann man 
aber nachreichen, an schon verkaufter Hardware kann man nichts mehr 
machen. Also versucht man, meist eher schlecht als recht, die Mängel per 
Software zu flicken.

Mit freundlichen Grüßen - Martin

von Florian H. (heeen)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ausserdem haben viele PCs noch haufenweise unausgelastete CPU-Kerne
> rumliegen. Warum nicht einmal etwas findet, das die auslastet?

Weil die Attacke insbesondere Laptops betrifft die auch mal auf Akku 
laufen sollen.

von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Es würde mich schon sehr wundern, wenn wiederholte Zugriffe nicht
> eingeplant wären, noch dazu bei der relativ läppischen Zahl von 138000.

Das kommt so aber in der Praxis normalerweise nicht vor.

Icke ®. schrieb:
> Die theoretische (und praktische) Möglichkeit, daß ein Programm
> wiederholt auf eine Speicherzelle zugreift, zählt m.E. zu den leicht
> vorhersehbaren Problemen.

Normalerweie laufen diese wiederholten Zugriffe aber komplett im Cache 
ab, und der Hauptspeicher sieht davon gar nichts. Daß ein Programm nach 
jedem einzelnen dieser Zugriffe auch gleich explizit angibt, daß der 
Wert sofort in den Speicher weitergeschrieben werden soll, ist ganz und 
gar nicht üblich. Schon gar nicht 138.000 mal in 65 ms. Wozu sollte das 
in einem normalen Anwendungsszenario überhaupt benötigt werden?

A. K. schrieb:
> Ich hoffe es sehr. Nur wundert mich mittlerweile in dieser Beziehung
> kaum noch etwas. Die Nach-Snowden Ära hat Verschwörungstheorien ja auch
> eine gänzlich neue Bedeutung verpasst.

Sie hat halt vor allem gezeigt, daß viele der Verschwörungstheorien ganz 
und gar nicht nur Spinnereien von Alufolienhut-Trägern sind.

von Uhu U. (uhu)


Bewertung
-2 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Daß ein Programm nach
> jedem einzelnen dieser Zugriffe auch gleich explizit angibt, daß der
> Wert sofort in den Speicher weitergeschrieben werden soll, ist ganz und
> gar nicht üblich.

Wie auch alle anderen Arten von Fehlern in der Computerei nicht üblich 
sind...

> Sie hat halt vor allem gezeigt, daß viele der Verschwörungstheorien ganz
> und gar nicht nur Spinnereien von Alufolienhut-Trägern sind.

Inhaltsloser Schwachsinn.

: Bearbeitet durch User
von Rolf Magnus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Rolf Magnus schrieb:
>> Daß ein Programm nach
>> jedem einzelnen dieser Zugriffe auch gleich explizit angibt, daß der
>> Wert sofort in den Speicher weitergeschrieben werden soll, ist ganz und
>> gar nicht üblich.
>
> Wie auch alle anderen Arten von Fehlern in der Computerei nicht üblich
> sind...

Und deshalb gibt es sie. Warum ist es bei diesem also so unglaublich, 
dass es ihn gibt? Sollte eben nicht sein, ist aber so. Wenn man ein 
Problem nicht versteht, heißt das nicht, daß es nicht da ist.

>> Sie hat halt vor allem gezeigt, daß viele der Verschwörungstheorien ganz
>> und gar nicht nur Spinnereien von Alufolienhut-Trägern sind.
>
> Inhaltsloser Schwachsinn.

Gut, nicht jeder hat aus der Snowden-Geschichte was gelernt.

von Icke ®. (49636b65)


Bewertung
1 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Normalerweie laufen diese wiederholten Zugriffe aber komplett im Cache
> ab, und der Hauptspeicher sieht davon gar nichts. Daß ein Programm nach
> jedem einzelnen dieser Zugriffe auch gleich explizit angibt, daß der
> Wert sofort in den Speicher weitergeschrieben werden soll, ist ganz und
> gar nicht üblich.

Das ist richtig und deswegen kommt es in der Praxis nicht zum Tragen. 
Aus Sicht eines Speicherdesigners müßte ich diesen Fall trotzdem 
einplanen, auch wenn er nicht üblich ist.

: Bearbeitet durch User
von Icke ®. (49636b65)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
X2 schrieb:
> Memtest kann das mittlerweile auch

Getestet, siehe Bilder. Eindreiviertel Stunden den Schmied gespielt und 
nix passiert. Zweiter Test läuft gerade mit anderem Riegel, nach 17 
Minuten noch Null Errors.

von Asko B. (dg2brs)


Bewertung
0 lesenswert
nicht lesenswert
@Icke

laut memtest2.jpg bist Du uns sowieso bereits
einen Tag vorraus. ;-)

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Asko B. schrieb:
> laut memtest2.jpg bist Du uns sowieso bereits
> einen Tag vorraus. ;-)

Verflixt, die haben meine CMOS-Uhr zerhämmert!!

Btw, mit dem zweiten und auch dritten Modul ebenfalls keine Fehler.

von Arc N. (arc)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Hab ich mir durchgelesen. Es läßt sich daraus schlußfolgern, daß
> bestimmte Systeme in der Tat anfällig für Bitfehler durch intensive
> Lesezugriffe sind. Es läßt sich aber NICHT schlußfolgern, daß mit der
> Methode GEZIELTE Bitmanipulationen möglich sind.

Siehe Google-Seite unter Kernel privilege escalation bzw.
"There are two things that help ensure that the bit flip has a high 
probability of being exploitable:
1. Rowhammer-induced bit flips tend to be repeatable...
2. We spray most of physical memory with page tables. This means that 
when a PTE's physical page number changes, there's a high probability 
that it will point to a page table for our process..."

> Ich bin kein Systemprogrammierer, könnte mit aber durchaus wirksame
> Gegenmaßnahmen auf OS-Ebene vorstellen. Zum einen nicht privilegierten
> Prozessen den Lesezugriff auf sensible Bereiche verwehren.

Das ist solchen Prozessen schon verwehrt...

> Zum anderen
> diese Bereiche redundant an verschiedenen Stellen im Speicher halten und
> zusätzlich mit Prüfsummen/CRC plausibilisieren.

Und wie oft soll das gemacht werden?
Die Google-Methode sucht mehr oder weniger gezielt nach Bit-Fehlern in 
Page-Table-Einträgen. Davon gibt's eine ganze Menge insb. wenn mmap und 
4 kiB-Seiten genutzt werden. Zudem "Huge pages cannot be swapped out 
under memory pressure."
https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

> Auf jeden Fall sehe ich in der Holzhammermethode
> keine besonders ernstzunehmende Gefahr.

Das kann man so sehen, muss man aber nicht...

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Das kann man so sehen, muss man aber nicht...

Er macht sich Sorgen ob des anstehenden Berufswechsels: ;-)

Icke ®. schrieb:
> Ich auch, ansonsten fall ich vom Glauben ab, mach meinen IT-Laden zu und
> laß mich zum Friedhofsgärtner umschulen...

: Bearbeitet durch User
von Arc N. (arc)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Arc Net schrieb:
>> Das kann man so sehen, muss man aber nicht...
>
> Er macht sich Sorgen ob des anstehenden Berufswechsels: ;-)
>
> Icke ®. schrieb:
>> Ich auch, ansonsten fall ich vom Glauben ab, mach meinen IT-Laden zu und
>> laß mich zum Friedhofsgärtner umschulen...

Ob das vor Row-Hammering schützt... Wer weiß, vielleicht ist die erste 
App mit passendem Grabpflegeroboter gar schon in Entwicklung ;)

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> 1. Rowhammer-induced bit flips tend to be repeatable.

Das heißt aber nicht, daß bestimmte Bits zuverlässig beeinflußt werden 
können. Grundsätzlich sind nur geladene Zellen anfällig, ungeladene 
können nicht aufgeladen werden. Die Orientierung der Zellen, d.h. ob sie 
im geladenen Zustand eine 1 oder eine 0 repräsentieren, ist auch nicht 
einheitlich. Die Speicherriegel bestehen intern sogar aus Mischungen 
verschieden orientierter Zellen. Wenn ich nun ein bestimmtes Bit auf 0 
kippen will, dieses aber in einer anti cell (aktiv 0) liegt, dann wirds 
nix. Weiterhin besteht kein zwingender Zusammenhang zwischen logischer 
und physischer Nachbarschaft von Zellen. Ein logisch benachbartes Bit 
kann physisch ein paar Reihen weiter oder gar (durch Remapping bedingt) 
sonstwo liegen. Und letztendlich ist sowieso nur ein Bruchteil der 
Zellen eines Riegels überhaupt anfällig für Bitflips. Den RAM komplett 
auf anfällige Zellen zu analysieren, kann laut Kim et al Tage dauern:

"This implies that
an exhaustive search for every possible victim cell would re-
quire a large number of iterations, necessitating several days
(or more) of continuous testing."

Die Chance, eine ganz bestimmte Zelle kippen zu können. ist also gar 
nicht sehr groß.
In den Blogs wird es teilweise so dargestellt, als ob die Googletruppe 
schon den Weg zum Rootrecht freigemacht hätte. In Wirklichkeit bedarf es 
einer ganzen Kette von Glücksumständen, um mit den Bitflips etwas 
sinnvolles anstellen zu können. Von einem echten Exploit noch weit 
entfernt.

> Das ist solchen Prozessen schon verwehrt.

Offensichtlich nicht, sonst wäre das Problem nicht existent.

> Die Google-Methode sucht mehr oder weniger gezielt nach Bit-Fehlern in
> Page-Table-Einträgen. Davon gibt's eine ganze Menge

Würde es nicht helfen, die page tables selbst redundant anzulegen und 
zyklisch die Konsistenz zu prüfen, sodaß Manipulationen auffallen?

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Er macht sich Sorgen ob des anstehenden Berufswechsels: ;-)

Spaten und Heckenschere habe ich schon mal bereitgelegt... =8P

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Würde es nicht helfen, die page tables selbst redundant anzulegen und
> zyklisch die Konsistenz zu prüfen, sodaß Manipulationen auffallen?

Jeder Prozess hat seine eigene Page Table... Wieviele Prozessorkerne 
wist du für den Quatsch spendieren und wieviel Strom?

Hardwarefehler - nichts anderes ist das - per Software reparieren zu 
wollen, ist eine Schnapsidee.

von Arc N. (arc)


Bewertung
1 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Und letztendlich ist sowieso nur ein Bruchteil der
> Zellen eines Riegels überhaupt anfällig für Bitflips. Den RAM komplett
> auf anfällige Zellen zu analysieren, kann laut Kim et al Tage dauern:

Daher auch das Spraying, welches vergleichbar auch bei anderen Exploits 
benutzt wird.
Der Exploit hier sprayed erst mal den Speicher mit Page-Table-Einträgen 
voll, versucht dann in irgendeinem dieser Einträge einen Bitfehler zu 
erzeugen, der dazu führt, dass danach ein anderer Page-Table-Eintrag im 
beschreibbaren Adressraum des Angreifers liegt (was er vorher nicht 
tat).
Ist ein solcher Eintrag erzeugt worden, bedeutet dies nichts anderes als 
uneingeschränkten Zugriff auf den gesamten Speicher...

> In den Blogs wird es teilweise so dargestellt, als ob die Googletruppe
> schon den Weg zum Rootrecht freigemacht hätte. In Wirklichkeit bedarf es
> einer ganzen Kette von Glücksumständen, um mit den Bitflips etwas
> sinnvolles anstellen zu können. Von einem echten Exploit noch weit
> entfernt.

Den Proof-of-Concept-Exploit kann man hier 
http://www.exploit-db.com/exploits/36310/ im Quelltext bekommen
http://www.exploit-db.com/sploits/36310.tar.gz

von Icke ®. (49636b65)


Bewertung
2 lesenswert
nicht lesenswert
Arc Net schrieb:
> Daher auch das Spraying, welches vergleichbar auch bei anderen Exploits
> benutzt wird.

Meine letzten praktischen Kontakte mit systemnaher Programmierung liegen 
ein wenig zurück, sprich letztes Jahrtausend. Ich mußte mich zunächst 
einlesen, habe das Prinzip der Attacke über die page tables aber nunmehr 
verstanden. Gut, sie funktioniert grundsätzlich. Das ändert aber nichts 
an meiner Ansicht, daß sie keine nenneswerte Bedrohung darstellt. Eher 
bestärkt es mich darin, weil für das Erreichen des letztendlichen 
Zieles, das Kompromittieren des Systems, ein hohes Maß an 
Voraussetzungen und auch "Glück" erforderlich sind. Basierend auf den 
Berichten und Zahlen von Kim et al und der Zero-Gruppe wären das u.a.:

1. Die Hardwareplattform muß grundsätzlich verwundbar sein. Mit ECC-RAM 
bestückte und/oder vor 2010 hergestellte Systeme sind so gut wie nicht 
betroffen.

2. Die RAM-Riegel müssen anfällig sein, es sind ~85% der getesteten.

3. Nur eine von 1700 Speicherzellen (0,06%) neigt zu Bitflips, eher 
weniger.

4. Die Zufallsanalyse mittels page table spraying erfordert große Mengen 
freien RAMs, um effizient und schnell arbeiten zu können.

5. Während des Hämmerns darf kein Refresh oder Zugriff durch andere 
Prozesse in die Quere kommen.

6. Eine page table aus dem Adressraum des angreifenden Prozesses muß 
durch Bitflips betroffen sein.

7. Die "Mutation" dieser page table(s) muß für weiteres Vorgehen nutzbar 
sein.

8. Das Betriebssystem muß gegen diese Art von Attacke anfällig sein.

9. Virtualisierung erschwert die Attacke oder verhindert sie ganz.

10. Kollateralschäden durch nicht beabsichtigte Bitflips können 
unvorhersehbare Auswirkungen haben, bis hin zum Absturz des Systems.

Man könnte nun die Wahrscheinlichkeit des Erfolges berechnen, wenn 
weitere statistische Daten wie Marktanteile der Systeme, mittlere 
Auslastungen usw. bekannt wären. Aber auch ohne Rechnung dürfte die 
Erfolgsquote nicht sonderlich hoch einzuschätzen sein.

Die für Hacker lohnenswertesten Ziele, nämlich Server, fallen aufgrund 
der Punkte 1 und 9 schon mal größtenteils weg. Von den anderen Systemen 
ist nur ein Teil anfällig. Außerdem existieren aufgrund von 
Sicherheitslücken in OS und Anwendungen jede Menge wesentlich einfachere 
Möglichkeiten, um das System zu infiltrieren. Also warum so umständlich?

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> 8. Das Betriebssystem muß gegen diese Art von Attacke anfällig sein.

Alle Betriebssyteme sind dafür anfällig. Einen wirksamen Schutz dagegen 
gibt es nicht.

> 9. Virtualisierung erschwert die Attacke oder verhindert sie ganz.

Wer sagt das? Auch virtualisierte Systeme haben Page Tables.

> 10. Kollateralschäden durch nicht beabsichtigte Bitflips können
> unvorhersehbare Auswirkungen haben, bis hin zum Absturz des Systems.

Das ist das eigentliche Problem. Die Bedrohungsszenarien sind so 
wacklig, dass damit bestensfalls Zufallstreffer zu erzielen sind.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Hardwarefehler - nichts anderes ist das - per Software reparieren zu
> wollen, ist eine Schnapsidee.

Besser als sie gar nicht zu reparieren. Und es ist auch ein sehr 
gängiger Weg, da sich Software in der Regel viel leichter und 
kostengünstiger tauschen läßt als die dazugehörige Hardware.
Oder sollen jetzt alle weltweit ihren Speicher (oder wenn der nicht 
ausbaubar ist, das ganze Gerät) wegwerfen und neu kaufen, wenn ein 
Betriebssystem-Update es auch täte?

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:

> Getestet, siehe Bilder. Eindreiviertel Stunden den Schmied gespielt und
> nix passiert. Zweiter Test läuft gerade mit anderem Riegel, nach 17
> Minuten noch Null Errors.

Grund für die Auswirkungen der Leseoperationen auf Nachbarzellen sind 
doch die kleineren Strukturbreiten. Da sind wir jetzt bei 25 nanometer 
(DDR3 80-25nm) und waren vor einigen Jahren bei DDR2 noch bei 100 - 60 
nm.

https://www.thomas-krenn.com/de/wiki/DDR-SDRAM

Dann ist doch davon auszugehen das ältere Riegel weniger bis garnicht 
"verletzlich" sind. Gibt es dazu eine Statistik?


Solche Crosstalk/Leckstrom-Probleme im IC sind für Hardwareentwickler 
nix neues, da gibt es einige bewehrte Gegenmaßnahmen. Eine ist die 
Flanken der Impulse nur so steil zu gestalten wie nötig. 
Mitverantwortlich für die Flankensteilheit ist die Bufferung der 
Betriebsspannung, die Kondensatoren zwischen Vcc und Masse. Gibt es da 
Erfahrung wie sich bspw das ESR der C auf das interne crosstalk 
auswirkt? Also Speicherriegel mit identsichen Speicher-IC aber anderen 
Modulhersteller mit anderen Kondensatoren.

MfG,

von Abdul K. (ehydra) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Bei modernen Chips sind oft Abblockkondensatoren (1. Stufe) und 
Spannungsregler mit auf dem Chip integriert. Vermutlich oft als 
parasitäre Strukturen.
Wer sich schon immer wunderte, warum manche CPLDs so viel Leistung 
verheizen, weiß es jetzt ;-) Es gibt z.B. ein Patent, da ist der 
Spannungsregler als äußerste Struktur am Rand des Chips rundherum 
verteilt angelegt.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:

> Hardwarefehler - nichts anderes ist das - per Software reparieren zu
> wollen, ist eine Schnapsidee.

Ne das ist gängige Praxis. Beispielsweise das wear-leveling bei 
Solidstatedisks und flash generell. Die billigen hochkapazitiven 
Multilevel Flash heute vertragen nur noch einige hundert Speicherzyklen. 
Also baut man die SSD mit super intelligenten Controllern und 
filesystemen bei denen keine Zelle überstrapaziert wird.

Alternativ könnte man natürlcich robustere Flash-Speicher verwenden 
(single-level, geringere Speicherdichte)

MfG,

von Dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:

> Würde es nicht helfen, die page tables selbst redundant anzulegen und
> zyklisch die Konsistenz zu prüfen, sodaß Manipulationen auffallen?

Gibt es schon, nennt sich ECC-Speicher.

Das gute an dem Bug wird wohl sein das Systeme mit ECC stärker im Markt 
nachgefragt werden. Leider ist das Angebot an günstigen Systemen mit ECC 
stark rückläufig.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Dirk schrieb:
> Leider ist das Angebot an günstigen Systemen mit ECC stark rückläufig.

Die Prozessoren können es und für passenden ECC-Speicher brauchts nur 
1-2 DRAM-Chips mehr auf dem Modul. Fehlt möglicherweise der BIOS 
Support, aber auch das steckt da im Grunde schon drin, ist nur mangels 
Bedarf mitunter abgeschaltet. Wenn also aufgrund RowHammer der Bedarf 
kommen sollte kann darauf recht schnell reagiert werden.

Sollte das BIOS kein Scrubbing vorsehen (regelmässiges Kontrolllesen um 
kumulierende Bitfehler zu vermeiden): Das lässt sich per Software 
harmlos nachrüsten.

: Bearbeitet durch User
von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Einen wirksamen Schutz dagegen gibt es nicht.

Theoretisch schon, wenn auch zu Lasten der Performance. Das OS muß 
eigentlich nur in so kurzen Abständen auf die page tables zugreifen, daß 
die Attacke keine Chance hat, die Zellentladung zu vollenden. Oder die 
page tables spiegeln. Ja, das ist nicht optimal, wäre aber eine 
Möglichkeit.

> Auch virtualisierte Systeme haben Page Tables.

Der Hypervisor muß lediglich die Ausführung der CLFLUSH Instruktion 
durch Gäste unterbinden und schon läuft die Attacke ins Leere (bzw. den 
CPU-Cache).

> Wer sagt das?

Die Zero-Truppe. Die haben nämlich genau dieses Feature in der NaCL 
Sandbox nachgerüstet. Steht in dem Blog.

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Dann ist doch davon auszugehen das ältere Riegel weniger bis garnicht
> "verletzlich" sind. Gibt es dazu eine Statistik?

Aus dem Paper von Kim et al läßt sich entnehmen, daß Systeme vor 2010 
kaum bis gar nicht betroffen sind und daß die Verwundbarkeit bei ganz 
neuen Systemen wieder zurückgeht. Siehe PDF-Seite 6, Figure 3.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Auch wenn es schon vom Ansatz her naheliegt halte ich angesichts der 
doch relativ geringen Anzahl der Module pro Zeitpunkt und der 
drastischen Streuung der Ergebnisse eine statistische Aussage der 
Entwicklung über die Jahre für mutig, insbesondere für 2014 mit nur 4 
Modulen insgesamt und davon 3 von einem Hersteller.

: Bearbeitet durch User
von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Sicher ist das nicht repräsentativ, aber zumindest ein Trend. Die RAM- 
und Boardhersteller werden sich bestimmt auch darauf einstellen.

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Besser als sie gar nicht zu reparieren. Und es ist auch ein sehr
> gängiger Weg, da sich Software in der Regel viel leichter und
> kostengünstiger tauschen läßt als die dazugehörige Hardware.

Sowas kann man per Software gar nicht zuverlässig reparieren und 
irgendwelche Hacks kosten jede Menge CPU-Leistung, bringen aber keine 
sichere Lösung.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Ne das ist gängige Praxis. Beispielsweise das wear-leveling bei
> Solidstatedisks und flash generell.

Das ist doch was völlig anderes, als RAMs, die auf kritische 
Zugriffmuster mit Informationsverlust reagieren.

Ausgelutschte Flash-Zellen sind kaputt, das ist Verschleiß; durch das 
Geschehen auf den Zugriffsleitungen kippende RAM-Zellen sind nicht 
kaputt - das ganze Design ist kaputt. Diese Art Fehler ist nur durch 
Hardware - also z.B. ECC - reparierbar.

Software geht davon aus, dass die Hardware genau das tut, was 
spezifiziert ist. Alles andere ist ganz einfach nicht praktikabel.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Theoretisch schon, wenn auch zu Lasten der Performance. Das OS muß
> eigentlich nur in so kurzen Abständen auf die page tables zugreifen, daß
> die Attacke keine Chance hat, die Zellentladung zu vollenden. Oder die
> page tables spiegeln. Ja, das ist nicht optimal, wäre aber eine
> Möglichkeit.

Alle 100.000 Speicherzyklen alle Page Tables durchnudeln? Was bleib da 
von der Speicherbandbreite übrig?

Und das erschwert nur Attacken auf die Page Tables. Provozierte 
Systemabstürze sind damit nich aus der Welt.

von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Fpga Kuechle schrieb:
>> Ne das ist gängige Praxis. Beispielsweise das wear-leveling bei
>> Solidstatedisks und flash generell.
>
> Das ist doch was völlig anderes, als RAMs, die auf kritische
> Zugriffmuster mit Informationsverlust reagieren.

Ja, es ist noch viel schlimmer, da sie auf kritische Zugriffsmuster 
sogar mit Defekt reagieren, und in diesem Fall sogar auf Zugriffsmuster, 
die auch in ganz normalen Standardsituationen vorkommen und nicht nur 
auf welche, die explizit provoziert werden müssen.

> Ausgelutschte Flash-Zellen sind kaputt, das ist Verschleiß;

Ja. Sie verschleißen aufgrund der eingesetzen Technologie so schnell, 
daß das für Standardanwendungen untragbar ist. Deshalb muß man außenrum 
irgendwelche ausgeklügelten Verfahren basteln, damit man sie trotzdem 
noch vernünftig nutzen kann.

> Software geht davon aus, dass die Hardware genau das tut, was
> spezifiziert ist. Alles andere ist ganz einfach nicht praktikabel.

Hardware geht dagegen immer öfter nicht mehr davon aus,daß die Software 
genau das tut, was spezifiziert ist. Das war früher mal so, aber da es 
zu oft vorkam, daß durch Fehler in der Software die Hardware zerstört 
wurde, werden heute entsprechende Sicherheitsvorkehrungen eingebaut.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Hardware geht dagegen immer öfter nicht mehr davon aus,daß die Software
> genau das tut, was spezifiziert ist.

Das würde ich anders formulieren:
Hardware wird im Idealfall so konzipiert, dass jede beliebige Software 
darauf keine bleibenden Schäden anrichten kann - vergleichbar mit der 
Eigensicherheit im Maschinenbau.

Es handelt sich nicht um ein Feature zur Bändigung "bösartiger" 
Software, sondern um eine Sicherung der Hardware vor sich selbst: sie 
wird vor Selbstbeschädigung geschützt. (Immerhin ist ja denkbar, dass 
dieser "bösartige" Code durch irgend welches schräges Verhalten der 
Hardware in den Speicher kommt und dann Rauchwölkchen auslöst...)

Die Bedeutung von Codebits ergibt sich aus der Hardware - aus sich 
selbst sind sie bedeutungslos.

: Bearbeitet durch User
von Arc N. (arc)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Dirk schrieb:
>> Leider ist das Angebot an günstigen Systemen mit ECC stark rückläufig.
>
> Die Prozessoren können es und für passenden ECC-Speicher brauchts nur
> 1-2 DRAM-Chips mehr auf dem Modul.

Intel sieht das etwas anders...
Core i7
http://ark.intel.com/de/search/advanced?s=t&FamilyText=4th%20Generation%20Intel%C2%AE%20Core%E2%84%A2%20i7%20Processors&ECCMemory=true

Core i5
http://ark.intel.com/de/search/advanced?s=t&FamilyText=4th%20Generation%20Intel%C2%AE%20Core%E2%84%A2%20i5%20Processors&ECCMemory=true

Nur ein paar unterstützen ECC...

Bei AMD können zwar z.B. die FX alle ECC, aber die APUs afaik nur in der 
eingelöteten Notebook-Variante.

Und dann müssen die Mainboards ECC auch unterstützen...

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Nur ein paar unterstützen ECC...

50 aktuelle Prozessoren für den Desktop-Bereich (von 202):
http://ark.intel.com/de/search/advanced?s=t&FilterCurrentProducts=true&MarketSegment=DT&ECCMemory=true

Letztlich ist das Intels Spiel mit den Features und der schier 
unendlichen Palette von Prozessoren. Technisch sind das nur relativ 
wenige wirklich verschiedene Dies, die sich in der Kennung und den 
freigeschalteten Features unterscheiden.

Daher sind praktisch alle Dies, die sowohl im Server- als auch im 
Desktop-Bereich eingesetzt werden, prinzipiell zu ECC fähig. Und so 
kommt man dann eben zu einem Celeron mit ECC, weil der gleiche Haswell 
drin steckt wie in einem irgendeinem Xeon E3.

> Und dann müssen die Mainboards ECC auch unterstützen...

Verdrahtung der Datenbits, und BIOS.

: Bearbeitet durch User
von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Arc Net schrieb:
> Bei AMD können zwar z.B. die FX alle ECC, aber die APUs afaik nur in der
> eingelöteten Notebook-Variante.

Yup. AMD ist eine andere Baustelle, weil die mittlerweile den 
Server-Markt praktisch nicht mehr bedienen.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Übrigens, ECC löst, anders wie der heise Artikel suggeriert, das Problem 
nicht wirklich.

ECC wie heute bei den ECC-Speicherriegeln eingesetzt korregiert nur wenn 
ein einziges bit im Wort kippt. Schon bei zwei bit im Wort gedreht ist 
der Fehler auch mit ECC nur durch reboot sicher korigierbar, bei drei 
bit ist es ganz schlimm, das wird nichtmal erkannt.

Und laut der Orginalquelle (danke für den link) S.8 Tab. 5 gab es am 
bspw für einen Riegel 9,8 Mio einbitfehler (korigierbar); 182 Tsd 
zweibitfehler (geordneter reboot); 2,3 Tsd drei-und 4bitfehlerfehler 
(nicht erkennbar) .

Wofür ECC heute eingesetzt wird und was es kann kann man aus dieser 
Meldung ablesen: 
http://www.heise.de/newsticker/meldung/Hauptspeicherfehler-sehr-viel-haeufiger-als-bisher-angenommen-828883.html


Dagegen hilft nur Speicher mit größerer Strukturbreite, also vielleicht 
etwa von vor 2011 gefertigt.

Vielleicht zeigt der Row-hammer ja auf das die Zeiten des immer mehr 
Speichers durch immer kleineren Strukturen vorbei ist - mal wieder Zeit 
nachzudenken Systen zu bauen/programmieren die auch mit weniger Speicher 
(ein paar Gigabyte) pro Core effizient arbeiten.


Wahrscheinlich genügt es auch schon wenn der Cache nicht deaktiviert 
oder von jedem entleert werden kann. Dann dürfte es für die Software 
nicht möglich sein in kürzester Zeit hunderttausend Mal hintereinander 
eine nicht geänderte Speicherzelle im Arbeitsspeicher auszulesen. Das 
deutet ja der heise Artikel so an.

MfG,

: Bearbeitet durch User
von gg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Dagegen hilft nur Speicher mit größerer Strukturbreite, also vielleicht
> etwa von vor 2011 gefertigt.

Na ein Glück das meine Kiste von 2008 mit 8GByte DDR2 noch schnell genug 
für alles was ich so mache ist ;-) ;-P

von Abdul K. (ehydra) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Übrigens, ECC löst, anders wie der heise Artikel suggeriert, das Problem
> nicht wirklich.
>
> ECC wie heute bei den ECC-Speicherriegeln eingesetzt korregiert nur wenn
> ein einziges bit im Wort kippt. Schon bei zwei bit im Wort gedreht ist
> der Fehler auch mit ECC nur durch reboot sicher korigierbar, bei drei
> bit ist es ganz schlimm, das wird nichtmal erkannt.
>
> Und laut der Orginalquelle (danke für den link) S.8 Tab. 5 gab es am
> bspw für einen Riegel 9,8 Mio einbitfehler (korigierbar); 182 Tsd
> zweibitfehler (geordneter reboot); 2,3 Tsd drei-und 4bitfehlerfehler
> (nicht erkennbar) .
>

Ist doch usus z.B. in der Raumfahrt einfach im Hintergrund den Speicher 
systematisch durchzulaufen und damit Einzelbitfehler vor dem möglichen 
Erscheinen eines zweiten Bitfehlers zu korrigieren. Dann reicht eine ECC 
1-Bit Korrekturmöglichkeit.


>
> Dagegen hilft nur Speicher mit größerer Strukturbreite, also vielleicht
> etwa von vor 2011 gefertigt.
>

Warte einfach den Hype ab. Die sehen darin alle die NSA.


Hach, wie gerne ich sowas lese:
"
> Vielleicht zeigt der Row-hammer ja auf das die Zeiten des immer mehr
> Speichers durch immer kleineren Strukturen vorbei ist - mal wieder Zeit
> nachzudenken Systen zu bauen/programmieren die auch mit weniger Speicher
> (ein paar Gigabyte) pro Core effizient arbeiten.
"
Wirklich, schnelle und sparsame Programme?? YMMD

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> ECC wie heute bei den ECC-Speicherriegeln eingesetzt korregiert nur wenn
> ein einziges bit im Wort kippt.

Zumindest in der häufigsten SECDED Implementierung. Bei Servern findet 
man allerdings mittlerweise öfter auch RAM-Mirroring als Option.

Eine andere Variante ist ein Speichersystem, bei dem der Totalausfall 
eines DRAM-Chips toleriert werden kann (bei IBM als "Chipkill" 
bezeichnet). Je nach Implementierung sind dabei deutlich mehr Bitfehler 
korrigierbar, oder ein Speicherwort wird so auf Module und RAM-Chips 
verteilt, dass kein Chip mehr als 1 Bit des Wortes enthält (was in 
diesem Zusammenhang die Wahrscheinlichkeit von Mehrbit-Fehlern 
reduziert).

> Schon bei zwei bit im Wort gedreht ist
> der Fehler auch mit ECC nur durch reboot sicher korigierbar,

Ein entscheidender Punkt ist aber, dass sowohl 1- wie 2-Bit-Fehler 
erkannt und protokolliert werden können. Da ein RowHammer Angriff jede 
Menge Fehler produziert stehen die Chancen recht gut, dass man einen 
entsprechenden Angriff schnell bemerkt. Und zwar mit ziemlich klarer 
Aussage, nicht bloss mit mysteriösen Crashes.

Da 2-Bit-Fehler zum automatischen Stop/Restart von Systemen mit ECC 
führen sollten, ist die Chance, mit einem Angriff mehr zu erreichen als 
einen DOS, ausgesprochen gering.

> Wahrscheinlich genügt es auch schon wenn der Cache nicht deaktiviert
> oder von jedem entleert werden kann.

Dazu sind ausserhalb virtualisierter Umgebung neue Prozessoren nötig, 
denn der entsprechende Befehl ist nicht privilegiert.

: Bearbeitet durch User
von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:
> Ist doch usus z.B. in der Raumfahrt einfach im Hintergrund den Speicher
> systematisch durchzulaufen und damit Einzelbitfehler vor dem möglichen
> Erscheinen eines zweiten Bitfehlers zu korrigieren.

Ist nicht bloss in der Raumfahrt üblich, sondern dürfte in jedem ernst 
zu nehmenden Server implementiert sein (memory scrubbing).

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
>> Wahrscheinlich genügt es auch schon wenn der Cache nicht deaktiviert
>> oder von jedem entleert werden kann.
>
> Dazu sind ausserhalb virtualisierter Umgebung neue Prozessoren nötig,
> denn der entsprechende Befehl ist nicht privilegiert.

Hm gibt es diese neuen Prozessoren in Form des Cortex-R schon? Da 
scheint zumindest das Verhalten des Daten-Caches nur von Privilierten 
änderbar:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363e/Bgbdbdjc.html

Der prefetch-cache ist jetz nur für Instructions ?

MfG,

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Hm gibt es diese neuen Prozessoren in Form des Cortex-R schon?

Da das RowHammer Thema sich im Code bisher ausschiesslich auf die 
PC-Welt bezog, tat ich das auch. Man könnte sich auch auf alte 
Prozessoren zurückbesinnen, die den CLFLUSH Befehl noch nicht kennen.

: Bearbeitet durch User
von Abdul K. (ehydra) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
War da nicht was von ladbaren Microcode bei Desktop-CPUs?

von Me2 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> scheitert eine solche Attacke auch daran, daß Speicherriegel in
> unterschiedlichsten Organisationen verbaut vorkommen und somit gar nicht
> gezielt nebeneinander liegende Zellen getroffen werden können

Sie es mal anders.

Wieviele Socken muss man maximal aus einem Wäschekorb herausfischen, um 
ein Paar in den Händen zu halten, wenn man weiß, dass zehn Paare im Korb 
sind.

Oder anders ausgedrückt, wieviele Speicherorganisationen gibt es und wie 
viele Rechner muss man dann statistisch betrachte angreifen, um einen 
mit einer zum Angriffsmuster passenden Organisation zu erwischen?

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:
> War da nicht was von ladbaren Microcode bei Desktop-CPUs?

Wäre auch eine Möglichkeit.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Fpga Kuechle schrieb:
>> Hm gibt es diese neuen Prozessoren in Form des Cortex-R schon?
>
> Da das RowHammer Thema sich im Code bisher ausschiesslich auf die
> PC-Welt bezog, tat ich das auch. Man könnte sich auch auf alte
> Prozessoren zurückbesinnen, die den CLFLUSH Befehl noch nicht kennen.

Meines Erachtens ist eine Lehre aus der Geschichte das der Datencache 
kein nice-to-have feature mehr ist sondern wegen der hier beschriebenen 
effekte aus Gründen der System-stabilität bei hochintegrierten SDRAM 
unverzichtbar geworden ist.

Sicher ist einem Ingenieur das problem beim Stress-Lesen aufgefallen und 
er hat gleich die Produktentwicklungen in Alarmzustand versetzt. Dann 
setzen sich alle an den Tisch und meist das managment spricht schon mal 
von völlig unrealistischen benchmarks die im Feld-Einsatz nie auftreten. 
Damit haben diese ja auch nicht völlig Unrecht. Also einigt man sich 
drauf die Spec respective Qualifikations-benschmarks dahin gehend zu 
ändern das nur noch Einsatzrelevante Szenarien durchgespielt werden - 
also der Cache aktiviert bleibt.

Auch wäre zu fragen ob Alltagsanwendungen ohne cache den Effekt auslösen 
können. Ohne jetzt nachgerechnet zu haben, scheint es für den bitflip 
nötig den selben unveränderten Speicherbereich  aller 10-100 (?) Takte 
erneut auszulesen und das hunderte Mal hintereinander. Womöglich noch 
ohne die Daten weiter prozessieren. Welche Algorithmus braucht so ein 
"Xtreme fast and long memory polling" ?

MfG,

: Bearbeitet durch User
von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Me2 schrieb:
> Oder anders ausgedrückt, wieviele Speicherorganisationen gibt es und wie
> viele Rechner muss man dann statistisch betrachte angreifen, um einen
> mit einer zum Angriffsmuster passenden Organisation zu erwischen?

Bei RowHammer sehe ich zwei Angriffsszenarien.

(1) DoS = Denial of Service. Alle PCs effektiv lahmlegen. Das kannst du 
überall mindestens ausprobieren.

(2) Der Versuch, ein System zu übernehmen/manipulieren. Das wäre dann 
wohl eher eine hochspezifische Attacke auf bekannte Systeme, nicht so 
sehr ein Fischzug querbeet. Sofern überhaupt realistisch möglich, ohne 
Horden schlafender Hunde zu wecken.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Welche Algorithmus braucht so ein
> "Xtreme fast and long memory polling" ?

Auch ohne CLFLUSH ist der Aufwand, Caching zu überwinden, überschaubar.

Da geht mit etwas Anlauf jeder Zugriff am L1 Cache vorbei:
  for i=0 to infinity
    Zugriff auf Adresse BASE+i*4K

Beim Pentium Pro war bereits ab dem dritten Zugriff der L1-Cache 
nutzlos.

Abhängig von exakter Implementierung, Anzahl Cache-Levels und 
Assoziativität wird das etwas aufwändiger und der Anlauf variiert, aber 
das Prinzip bleibt ähnlich.

Das muss letztlich auch nicht langsamer sein als die CLFLUSH Variante. 
Dieser Befehl ist nämlich schweinelangsam.

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
1 lesenswert
nicht lesenswert
Fpga Kuechle schrieb:
> Dagegen hilft nur Speicher mit größerer Strukturbreite, also vielleicht
> etwa von vor 2011 gefertigt.

Oder ein ECC-Verfahren mit höherer Redundanz und besseren 
Korrekturfähigkeiten.

von Icke ®. (49636b65)


Bewertung
1 lesenswert
nicht lesenswert
Me2 schrieb:
> Oder anders ausgedrückt, wieviele Speicherorganisationen gibt es und wie
> viele Rechner muss man dann statistisch betrachte angreifen, um einen
> mit einer zum Angriffsmuster passenden Organisation zu erwischen?

Das ist gar nicht notwendig. Ich muß zugeben, die Problematik anfangs 
etwas zu oberflächlich betarchtet zu haben. Mir ist jetzt aber klar, daß 
man bei dem "Bruteforce" Angriff auf die page tables die 
Speicherorganisation gar nicht kennen muß.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Fpga Kuechle schrieb:
>> Dagegen hilft nur Speicher mit größerer Strukturbreite, also vielleicht
>> etwa von vor 2011 gefertigt.
>
> Oder ein ECC-Verfahren mit höherer Redundanz und besseren
> Korrekturfähigkeiten.

Nein, der verhindert nicht grundsätzlich das das Problem auftritt, er 
verbessert nur die Kompensation auf Kosten der Speichereffizienz und 
Leistungsaufnahme.
Und wenn die Wahl ist zwischen bspw. 2 Riegel "alter" Speicher a 4 GByte 
gegen einem Riegel 8 Gbyte neuer Speicher  + 2Gbyte Parity ECC plus 
steuerlogic + vorbereites Motherboard dann fällt die Entscheidung sicher 
für den Speicher mit 0.000% Probleme statt zu dem mit ECC mit 0,0001% 
Problem.

MfG,

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.