Hallo

Bei golem las ich eben über Zenhammer was das gleiche wie Rowhammer nur
bei AMD sein solle. Nur, warum tun die so als sei das als CPU-Bug ein zu
stufen? Nach meinem Verständnis ist das einzig CPU-abhängige Feature ein
mißbräuchlich verwendeter CFLUSH befehl und die schiere Möglichkeit in
hoher Frequenz zwei verschiedene Speicher-seiten oder DRAM-Reihen lesen
zu können. Beides kann man kaum einer CPU als Fehler anlasten.

Und warum geht jetzt keiner auf die DRAM-Hersteller los und das die ihre
RAM Bausteine entsprechend nachbessern? Denn offenbar liegt das problem
im Zeilenpuffer des DRAM Moduls der beim Umladen zwischen zwei reihen
fehler machen könnte. Reparieren, RAMs austauschen da wo's nötig ist und
gut ist.

Stattdessen scheint man mit diversen Patches (PaX u.s.) der CPU
verbieten wollen dies oder jenes überhaupt zu tun.

Klingt wie Denkverbot oder lautes "Lalala" rufen wenn einem was nicht
gefällt. WTF?

Bye/
/Kay

--
nix

Am 27.03.24 um 14:22 schrieb Kay Martinen:
> Bei golem las ich eben über Zenhammer was das gleiche wie Rowhammer nur
> bei AMD sein solle. Nur, warum tun die so als sei das als CPU-Bug ein zu
> stufen? Nach meinem Verständnis ist das einzig CPU-abhängige Feature ein
> mißbräuchlich verwendeter CFLUSH befehl und die schiere Möglichkeit in
> hoher Frequenz zwei verschiedene Speicher-seiten oder DRAM-Reihen lesen
> zu können. Beides kann man kaum einer CPU als Fehler anlasten.

Ack.

> Und warum geht jetzt keiner auf die DRAM-Hersteller los und das die ihre
> RAM Bausteine entsprechend nachbessern?

Weil die DRAM-Technik inhärent anfällig gegen solche Attacken ist.

> Denn offenbar liegt das problem
> im Zeilenpuffer des DRAM Moduls der beim Umladen zwischen zwei reihen
> fehler machen könnte. Reparieren, RAMs austauschen da wo's nötig ist und
> gut ist.

Nein, ECC-RAM rein, so wie in jedem ernstzunehmenden Server, und die
ganzen *-Hammer einfach ignorieren.

Die Wahrscheinlichkeiten für einen Mehrfachfehler, der ECC durch die
Lappen geht, dürfte im Bezug auf die typische Lebenserwartung eines
Rechners kaum relevante Dimensionen erreichen.

> Stattdessen scheint man mit diversen Patches (PaX u.s.) der CPU
> verbieten wollen dies oder jenes überhaupt zu tun.

Das halte ich auch nicht für sinnvoll.

Marcel

Am 27.03.24 um 21:24 schrieb Marcel Mueller:
> Am 27.03.24 um 14:22 schrieb Kay Martinen:
>> Feature ein mißbräuchlich verwendeter CFLUSH befehl und die schiere
>> Möglichkeit in hoher Frequenz zwei verschiedene Speicher-seiten oder
>> DRAM-Reihen lesen zu können. Beides kann man kaum einer CPU als Fehler
>> anlasten.
>
> Ack.

Gut. Hab ich mich also doch nicht verlesen.

>> Und warum geht jetzt keiner auf die DRAM-Hersteller los und das die
>> ihre RAM Bausteine entsprechend nachbessern?
>
> Weil die DRAM-Technik inhärent anfällig gegen solche Attacken ist.

Wenn es aber; wie beschrieben wird; am Zeilenpuffer im DRAM liegt das
Bits kippen könnten bei wiederholten Zugriffen auf die gleiche Reihe
dann frage ich mich ob das nicht ebenfalls zu problemen führen müsste
wenn die CPU speicherbereiche umkopieren will. Dabei kann es ebenfalls
zu wiederholten Zugriffen auf eine Speicherreihe kommen. Je nach Abstand
R + W in einem Modul oder Read in einem Modul und Write in einem
anderen, oder auch überlappend. Müßten da nicht auch schon rein
statistisch bitflips dabei sein die auf Desktops ohne ECC schlicht nicht
erkannt werden - und zu bisher unerkannten Daten/Programmfehlern führen
sollten?

Schon klar, DRAMs sind eben keine Statischen RAMs aber wenn der Inhalt
einer Reihe in den Puffer geladen wurde dann sollte der mit dem inhalt
der Reihe synchron bleiben meine ich. Ansonsten: Fehlerhafte
Implementierung!?

Das wäre in etwa so sinnvoll wie ein Carry-Flag in der CPU das bei
wiedeholtem Lesen nur "manchmal" den richtigen Übertrags-status angibt.

Oder beispielsweise das PM-Flag. Hups, ein Bitflip und schon ist das
Programm im Real-Mode gefangen-> Crash!

Hmm. Die CPU-Flags werden bei Kontext-wechsel im TSS gesichert, und die
anderen Status-register die man evtl. nur im Ring 0 erreicht oder
modifizieren kann? TSS = Irgendein RAM-Bereich, IMO lt. GDT. x-tausend
Leseversuche aus Ring 3 auf Verbotenes sollten doch schon beim 1.
Versuch eine Exception werfen oder? Jedenfalls nehme ich an das es bei
heutigem Flat-Memory use-case ebenso geschützt wäre wie das im
Segmentierten Modell ab i386 vorgesehen war. DEP?

>> Denn offenbar liegt das problem im Zeilenpuffer des DRAM Moduls der
>> beim Umladen zwischen zwei reihen fehler machen könnte. Reparieren,
>> RAMs austauschen da wo's nötig ist und gut ist.
>
> Nein, ECC-RAM rein, so wie in jedem ernstzunehmenden Server, und die
> ganzen *-Hammer einfach ignorieren.

Im Artikel oder Kommentaren hieß es das auch ECC kein "Heilmittel" wäre.
Bestenfalls wenn die RAMs ECC selbst machten. Und war da nicht etwas bei
dem es immer hieß manche CPUs könnten zwar ECC aber das Feature sei bei
einigen Deaktiviert, vom Chipsatz nicht unterstützt, auf Xeon ja, auf
Pentium nein - obwohl es faktisch die gleiche Architektur wär.

Am Ende hängt der Server in einem NMI wg. ECC und du hast einen DoS
auslöser gebaut mit der Attacke. Besser ist das nur weil der Angreifer
nach dem Reboot wieder bei null anfangen muß. Der Server steht dennoch
erst mal im Off.

> Die Wahrscheinlichkeiten für einen Mehrfachfehler, der ECC durch die
> Lappen geht, dürfte im Bezug auf die typische Lebenserwartung eines
> Rechners kaum relevante Dimensionen erreichen.

Parity (wenn's denn noch implementiert wäre) kann ja eh nur
einzelbit-fehler erkennen, bei zwei Bitflips zugleich ist ja schon die
Frage welches denn das richtige ist. ECC sollte doch genau
mehrfach-bitfehler erkennen können. Das Limit dort war IMO mal 2 Bits
oder sind es nun mehr, oder alle (64, 128, ???)Datenbits des Busses
DRAM-CPU?

Ich mach mir das jetzt auch keine Sorgen das dies Effektivere Angriffe
leichter machte, aber...

>> Stattdessen scheint man mit diversen Patches (PaX u.s.) der CPU
>> verbieten wollen dies oder jenes überhaupt zu tun.
>
> Das halte ich auch nicht für sinnvoll.

.... das diese Diversen Patch-versuche am "drumherum" die Leistung der
CPU noch mal deutlich reduzieren (so wie bei Meltdown/Spectre
Mitigations) das sorgt mich eher.

Was die Verkäufe von Neu-HW ankurbeln könnte.
Man könnte fast glauben das sei die Negativ-Alternative zum Feature X in
CPU frei schalten durch Geldeinwurf und Lizenz-kauf.

Zumindest bei Linux würde ich erwarten das man solche Mitigations bei
bedarf durch einen kernelparameter ab schalten könnte. Immerhin ging es
bei den anderen bisher auch. Und Software-Patches im System kann man
ggf. deinstallieren oder deaktivieren. Notfalls kernel selbst bauen.

Ob das bei Windows auch so einfach ist bezweifele ich.

Ob diese "Hammer" varianten wohl auch mit einer In-Order Architektur
(atom, ppro, i686) möglich sind? Seit wann ist CFLUSH implementiert?

Zeit bis Erfolg: <unendlich> ;)

Bye/
/Kay

--
nix

On 3/28/24 00:46, Kay Martinen wrote:
>
>
> Am 27.03.24 um 21:24 schrieb Marcel Mueller:
>> Am 27.03.24 um 14:22 schrieb Kay Martinen:
>>> Feature ein mißbräuchlich verwendeter CFLUSH befehl und die schiere
>>> Möglichkeit in hoher Frequenz zwei verschiedene Speicher-seiten oder
>>> DRAM-Reihen lesen zu können. Beides kann man kaum einer CPU als
>>> Fehler anlasten.
>>
>> Ack.
>
> Gut. Hab ich mich also doch nicht verlesen.
>
>>> Und warum geht jetzt keiner auf die DRAM-Hersteller los und das die
>>> ihre RAM Bausteine entsprechend nachbessern?
>>
>> Weil die DRAM-Technik inhärent anfällig gegen solche Attacken ist.
>
> Wenn es aber; wie beschrieben wird; am Zeilenpuffer im DRAM liegt das
> Bits kippen könnten bei wiederholten Zugriffen auf die gleiche Reihe
> dann frage ich mich ob das nicht ebenfalls zu problemen führen müsste
> wenn die CPU speicherbereiche umkopieren will. Dabei kann es ebenfalls
> zu wiederholten Zugriffen auf eine Speicherreihe kommen. Je nach Abstand
> R + W in einem Modul oder Read in einem Modul und Write in einem
> anderen, oder auch überlappend. Müßten da nicht auch schon rein
> statistisch bitflips dabei sein die auf Desktops ohne ECC schlicht nicht
> erkannt werden - und zu bisher unerkannten Daten/Programmfehlern führen
> sollten?
>
> Schon klar, DRAMs sind eben keine Statischen RAMs aber wenn der Inhalt
> einer Reihe in den Puffer geladen wurde dann sollte der mit dem inhalt
> der Reihe synchron bleiben meine ich.

Das Auslesen ist bei DRAM zerstörend. Bei einem Lesezyklus werden die
Zellen einer Row auf die Leseverstärker geschaltet. Da eine Zelle im
Vergleich zur Leitung sehr klein ist ist ihr Inhalt danach weg. Der
Leseverstärker merkt sich das aber und schreibt am Ende des Zyklus die
Werte zurück.

Wenn das wiederholte Auslesen derselben Row zu Datenfehlern dort führt
ist das ein Designfehler im DRAM.

>>> Denn offenbar liegt das problem im Zeilenpuffer des DRAM Moduls der
>>> beim Umladen zwischen zwei reihen fehler machen könnte. Reparieren,
>>> RAMs austauschen da wo's nötig ist und gut ist.
>>
>> Nein, ECC-RAM rein, so wie in jedem ernstzunehmenden Server, und die
>> ganzen *-Hammer einfach ignorieren.
>
> Im Artikel oder Kommentaren hieß es das auch ECC kein "Heilmittel" wäre.

Es ist nicht 100%, aber Einzelbitfehler und Zweibitfehler sind bei
solchen Angriffen deutlich häufiger als der Rest. Du wirst also eine
Menge Einträge in den Logs (Einzelbitfehler) und System panics
(Zweibitfehler) bemerken. Speziell letztere sollten auffallen.

> Bestenfalls wenn die RAMs ECC selbst machten.

Ist das nicht bei DDR5 der Fall?

> ECC sollte doch genau
> mehrfach-bitfehler erkennen können. Das Limit dort war IMO mal 2 Bits
> oder sind es nun mehr, oder alle (64, 128, ???)Datenbits des Busses
> DRAM-CPU?

Standard ist Einbitfehler korrigieren und Zweibitfehler erkennen. Es
geht aber mehr wenn man will. Braucht halt zusätzliche Bits im RAM.

Hier ist ECC-RAM in der Kiste.

Gerrit

Am 28.03.24 um 00:46 schrieb Kay Martinen:
>> Weil die DRAM-Technik inhärent anfällig gegen solche Attacken ist.
>
> Wenn es aber; wie beschrieben wird; am Zeilenpuffer im DRAM liegt das
> Bits kippen könnten bei wiederholten Zugriffen auf die gleiche Reihe
> dann frage ich mich ob das nicht ebenfalls zu problemen führen müsste
> wenn die CPU speicherbereiche umkopieren will. Dabei kann es ebenfalls
> zu wiederholten Zugriffen auf eine Speicherreihe kommen. Je nach Abstand
> R + W in einem Modul oder Read in einem Modul und Write in einem
> anderen, oder auch überlappend. Müßten da nicht auch schon rein
> statistisch bitflips dabei sein die auf Desktops ohne ECC schlicht nicht
> erkannt werden - und zu bisher unerkannten Daten/Programmfehlern führen
> sollten?

Da muss man schon ein paar Zehnerpotenzen öfter auf die Speicherzellen
einhämmern.

>> Nein, ECC-RAM rein, so wie in jedem ernstzunehmenden Server, und die
>> ganzen *-Hammer einfach ignorieren.
>
> Im Artikel oder Kommentaren hieß es das auch ECC kein "Heilmittel" wäre.

Die können von mir aus schreiben, was sie wollen.

Ich habe es vor einiger Zeit mal auf meinem AMD-Server ausprobiert. Ein
C-Programm musste 3 Tage und Nächte lang auf dem RAM herumhacken, bis
das erste Bit gekippt ist. Und das hat ECC dann umgehend korrigiert.

Für einen Doppelbitfehler müsste man ein vielfaches länger hacken, und
der wird von ECC immer noch erkannt. Erst ein 3-Bit Fehler könnte eine
unerkannte Änderung verursachen. Das ist aber kaum zu schaffen, weil in
der Zeit keiner der häufigeren Doppelbitfehler auftreten darf, der
sofort zu einem NMI gefolgt von einem System-Stop aus Sicherheitsgründen
führen würde.

> Bestenfalls wenn die RAMs ECC selbst machten.

Das ist vollkommen egal, wer korrigiert. Im Gegenteil, ECC im
Speichercontroller korrigiert auch Fehler auf dem Bus, und die sind gar
nicht so selten, weil das Signal-Rauschverhältnis bei den Frequenzen gar
nicht so gut ist, wie man es gerne hätte.

> Und war da nicht etwas bei
> dem es immer hieß manche CPUs könnten zwar ECC aber das Feature sei bei
> einigen Deaktiviert, vom Chipsatz nicht unterstützt, auf Xeon ja, auf
> Pentium nein - obwohl es faktisch die gleiche Architektur wär.

Ja, Intel kastriert die billigeren CPUs, um sich nicht selbst Konkurrenz
zu machen.
AMD ist da gutmütiger. Früher konnte es alle, bis auf ein paar APUs die
es gar nicht als Server-Varianten gab und die es nicht implementiert hatten.
Mittlerweile ist AMD dazu übergegangen, es für die Desktopmodelle
einfach nicht mehr offiziell zu garantieren. In der Praxis sind das aber
nicht die typischen Funktionseinheiten, die zum Aussortieren einer CPU
führen. Kurzum, es funktioniert praktisch immer.

> Am Ende hängt der Server in einem NMI wg. ECC und du hast einen DoS
> auslöser gebaut mit der Attacke.

Ja.
Dafür gibt es aber wahrlich einfachere Wege, die nicht in jedem
Prozessmonitor mit 24/7 100% CPU-Last auf dem Schirm stehen.

> Besser ist das nur weil der Angreifer
> nach dem Reboot wieder bei null anfangen muß. Der Server steht dennoch
> erst mal im Off.

Vorher dürften die hunderten von Einzelbitfehlern aber schon längst ein
Wartungstechniker auf den Plan gerufen haben.

>> Die Wahrscheinlichkeiten für einen Mehrfachfehler, der ECC durch die
>> Lappen geht, dürfte im Bezug auf die typische Lebenserwartung eines
>> Rechners kaum relevante Dimensionen erreichen.
>
> Parity (wenn's denn noch implementiert wäre) kann ja eh nur
> einzelbit-fehler erkennen,

Gibt's seit Jahrzehnten nicht mehr.
Heute sind 64 Bit + 8 Bit ECC üblich.

> bei zwei Bitflips zugleich ist ja schon die
> Frage welches denn das richtige ist. ECC sollte doch genau
> mehrfach-bitfehler erkennen können. Das Limit dort war IMO mal 2 Bits
> oder sind es nun mehr, oder alle (64, 128, ???)Datenbits des Busses
> DRAM-CPU?

1 Bit sind immer korrigierbar,
2 Bit sind immer erkennbar

>>> Stattdessen scheint man mit diversen Patches (PaX u.s.) der CPU
>>> verbieten wollen dies oder jenes überhaupt zu tun.
>>
>> Das halte ich auch nicht für sinnvoll.
>
> ... das diese Diversen Patch-versuche am "drumherum" die Leistung der
> CPU noch mal deutlich reduzieren (so wie bei Meltdown/Spectre
> Mitigations) das sorgt mich eher.
>
> Was die Verkäufe von Neu-HW ankurbeln könnte.
> Magn könnte fast glauben das sei die Negativ-Alternative zum Feature X in
> CPU frei schalten durch Geldeinwurf und Lizenz-kauf.

Kann mir kaum vorstellen, dass man das sinnvoll monetarisieren kann.
Wenn dann eher über Kursmanipulationen in Kombination mit Leerverkäufen.

> Zumindest bei Linux würde ich erwarten das man solche Mitigations bei
> bedarf durch einen kernelparameter ab schalten könnte. Immerhin ging es
> bei den anderen bisher auch.

Das ist üblich.

> Und Software-Patches im System kann man
> ggf. deinstallieren oder deaktivieren. Notfalls kernel selbst bauen.

Wenn du Langeweile hast.

> Ob das bei Windows auch so einfach ist bezweifele ich.

In der Regsitry kann man den Kernel auch ganz ordentlich vergewaltigen.
Aber das macht normalerweise niemand, der noch halbwegs bei Verstand ist.

> Ob diese "Hammer" varianten wohl auch mit einer In-Order Architektur
> (atom, ppro, i686) möglich sind?

Keine Ahnung.

> Seit wann ist CFLUSH implementiert?

Seit SSE2.

Marcel