News Linus Torvalds: „Intel tötet den ECC-Standard“

Bei manchen frage ich mich ob diese mehr als die Überschrift gelesen haben.

In seiner direkten Art bemängelt Linus Torvalt die unzurechende Lösung der mangelnden Sicherheit der Intelprozessoren. Eine einfache "Lösung" für dieses Sicherheitsproblem ist halt ECC Speicher. Und dieses gibt es bei Intel für den Aufpreis von "bis zum 5x des Preises" (ich sehe da nicht das er alle Features kostenlos haben will). Es geht ja immer noch um PCs und deren sichere und unverfälschte Arbeitsweise. (es sind nicht HC oder Konsolen gemeint). Un dafür will er halt eine bezahlbare Möglichkeit haben. AMd bietet diese, zumindest inoffizell bei sehr vielen (nur ausnahmsweise nicht), und bei Intel nicht (bis auf Ausnahmen).

Auch gibt es einen Unterschied zwischen den einen Quasimonopolisten mit 90% Marktanteil und einen Herausforder mit bestenfalls 10% Marktanteil beim Durchsetzen eines Features( ECC). Zumal AMD nur in Ausnhamefälle im professionellen Umfeld zum Zuge gekommen ist. Selbst wenn man wollte, wurde es im Grunde nicht angeboten. Dafür das AMD Prozessoren nicht angeboten worden sind, ist ja auch Intel für verantwortlicht (siehe diverse "Verurteilungen" wegen Marktmissbrauch).
Auch ist AMD bei den Sicherheitslücken in in dem gleichen Ausmaß wie Intel betroffen. Mercedes hat ja auch nachdem die damalige A-Klasse beim Elchtest durchgefallen ist, allen Autos das Aufpreispfliche Feature EPS spendiert.

https://de.wikipedia.org/wiki/Elchtest
 
also....
...wenn linus eine amd workstation verwendet, erfolgreich, sind hohe anforderungen wohl erfüllt, so seh ich das wenigstens.
 
@bitheat
nein, siehe dazu den beitrag von 0x8100:
0x8100 schrieb:
ddr5 hat ecc "on-die", kann also speicherfehler, die im ram selbst auftreten, korregieren, ohne dass die cpu was davon mitbekommt. bleiben noch speicherfehler, die auf dem weg zwischen ram und cpu entstehen und die frage, ob nicht korrigierbare multi-bit-fehler auch an das system gemeldet werden.
 
Uskok1530 schrieb:
Somit ist der faktische Nutzen von ECC gegen Rowhammer basierte Attacken faktisch wertlos.
Generell wertlos ist es jetzt auch nicht, weil es ja nicht mit allen Rowhammer-Varianten umgangen werden kann. ECC wäre bzgl. Rowhammer zumindest kein Nachteil, würde aber ohne Mehraufwand zumindest schonmal einen Teil der Attacken abfedern, also eine zusätzliche Barriere zu den anderen Abwehrmaßnahmen. Mit ECC hätte man im Endeffekt zumindest einen Teilschutz "gratis".
 
begin_prog schrieb:
Bei AMD funktioniert ECC doch nicht nur theoretisch, sondern auch praktisch.


1. Es ist nicht offiziell und soweit mir bekannt ist es bis heute nicht beweisen, dass unter AM4 z. B. Multibit Fehler auch wirklich korrigiert werden etc. Genau darauf wollten ZeroStrat und ich raus. Lasse mich gerne aber korrigieren. Das hat auch nichts damit zu tun, was das System meldet. Eben weil es ja inoffiziell ist und AMD hier auch kein Wort verliert. Das ist der feine Unterschied. Bei offiziellen Support ist sowas eben in Whtiepapers auch dokumentiert etc.

2. Eines der beliebtesten X570 Boards unterstützt es direkt nicht. Mein Asus Strix X570-E kann es definitiv nicht. Somit ist es gefrickel bis man alles zusammen hat uns es auch garantiert funktioniert. Der Unterschied ist: wir haben hier im Office auch dicke Workstations mir TR Pro etc. wo eben auch der Hersteller es garantiert, dass es funktioniert mit entsprechenden vertraglichen Regelungen.

3. Natürlich kostet ECC Geld und Leistung mit faktisch keinen Vorteil für den Consumer Markt. Wir reden hier nicht vom professionellen Server Markt. Natürlich würde ich im professionellen Umfeld niemals eine Serverlandschadt ohne RDIMM und ECC betreiben. Genau aber darum geht es ja Torvald. Ich verantworte die gesamte IT eines recht großen EVU Konzerns als CIO und die Kosten für die Infrastruktur sind heute zu tage eher für unsere Branche eine vernachlässigbare Größe somit: welches Interesse sollte ich im kommerziellen Umfeld haben irgendwelche "Bastellösungen" nutzen zu können? Dies erklärt Torval nicht so ganz in seiner Ausführung.

Gegen Rowhammer Attacken ist ECC KEIN Schutz. Dafür wurde mit DDR4 eben ein elaboriertes Verfahren vorgestellt und auch von allen NAND Herstellern implementiert, was aber bei LDDR4 auch anfällig ist durch veränderte Row Patterns. Allen gemein ist, aber das nun mal grundsätzlich Angreifer mehrere Bits problemlos kippen können.

4. Nur weil Multi Bit Support in Windows gemeldet wird, sagt es nicht aus über den Fehlererkennung und auch die Fehlerbehebung. Siehe 1. Des weiteren habe ich starke Zweifel bei der Befähigung von normalen Computernutzern der WHEA Log auf nicht korriegbare Speicherfehler durchzusuchen und irgendwas daraus zuleiten. Dazu machen wir sowas nicht mal bei den normalen Desktop Rechner der MA weil bei solchen Büro Rechnern vielleicht ein 1-Bit Fehler alle 10 Jahre auftritt und dann ist die Frage wo dieser Fehler auftritt.

5. Wenn man ECC sagt und es um kosmische Strahlung geht müsste man auch auch direkt RDIMM sagen. Aber gut.
 
  • Gefällt mir
Reaktionen: RalphS, TouchGameplay und noxon
Da hat sich in den letzten 20 Jahren nix geändert.

Vorschlag für den nächsten Rant: Consumer CPUs unterstützen zuwenige PCIe Lanes
 
  • Gefällt mir
Reaktionen: AlphaKaninchen, TouchGameplay, Twin_Four und 3 andere
HPTaff schrieb:
Habe ich noch nie begriffen, dass ECC nicht auch im Desktop angeboten wird, speziell auf den HEDT Plattformen. Gut, dass da nun Druck entsteht. Bei breiter Anwendung würden auch die Preise fallen.
Weil es unnötig ist, sie schlechtere Zugriffszeiten haben, sie langsamer sind und deutlich teurer sind.
 
  • Gefällt mir
Reaktionen: RalphS
DocWindows schrieb:
Es wäre schon viel geholfen wenn endlich mal alle RAM-Riegel ordentlich auf allen Mainboards und mit allen Chipsätzen/CPUs laufen würden. Echte Fehler beim RAM hatten wir hier vor 15 Jahren. Die Qualität hat sich aber über die Jahre dramatisch verbessert, so dass wir mittlerweile genau 0 Server haben die noch ECC RAM drin haben. Früher war das ein Muss.

Sag mir doch bitte den Namen der Firma die kein ECC auf seinen Systemen einsetzt damit ich einen großen Bogen um dieses Unternehmen machen kann
Ergänzung ()

Banned schrieb:
Aber das Wichtigste fehlt in meinen Augen: Mit DDR5 könnte sich das Thema eh erledigt haben.
Hat es sich nicht. Weil die Übertragung RAM <-> CPU nicht gesichert wird.
 
  • Gefällt mir
Reaktionen: Balikon
cgs schrieb:
Vorschlag für den nächsten Rant: Consumer CPUs unterstützen zuwenige PCIe Lanes
Tun sie halt leider auch. Speziell im Zeitalter von NVMe-Speicher und 16-Kern Consumer-CPUs wird es langsam mal Zeit, dass die CPUs mehr PCIe-Lanes bekommen.
 
Uskok1530 schrieb:
1. Es ist nicht offiziell und soweit mir bekannt ist es bis heute nicht beweisen, dass unter AM4 z. B. Multibit Fehler auch wirklich korrigiert werden etc.
Multi-Bit-Fehler werden m.W. mit "normalem/handelsüblichen" ECC-RAM doch ohnehin nie korrigiert, sondern können nur erkannt werden. Nur 1-Bit-Fehler können auch korrigiert werden.

Oder irre ich mich da?
 
  • Gefällt mir
Reaktionen: mibbio, lasbo und gr1zzly
Es geht einfach, und das weiss auch Herr Torvalds, um den schoeden Mammon.
Und nicht, so schoen es auch waere, um dem User etwas Gutes zu tun.
 
ZeroStrat schrieb:
Ja eben, einfach nur ein Flag vom Board/BIOS abzufragen, heißt ja noch nichts. Eigentlich müsste man Fehler provozieren, um zu testen, ob's wirklich greift/korrigiert.
Wie würde man denn sowas unter Linux machen?
 
Biedermeyer schrieb:
Es geht einfach, und das weiss auch Herr Torvalds, um den schoeden Mammon.
Und nicht, so schoen es auch waere, um dem User etwas Gutes zu tun.
Du musst die CPUs aber auch irgendwie klassifizieren.
Wenn du selbst die kleinste Consumer CPU mit allen Features ausstattest, dann musst du die auch für 1000€ verkaufen um die entsprechenden Gewinne machen zu können.
Die Preise im Consumermarkt lassen sich ja nur so gestalten, weil die Prozessoren im Serverbereich nicht zu gebrauchen sind.
Gamer bekommen nur so günstig ihre Consumer CPUs, weil Geschäftskunden überdurchschnittlich viel für ihre Server-CPUs zahlen. So ist das nunmal. Ich weiß gar nicht, was es da zu meckern gibt, insbesondere, weil Consumer dieses Feature wirklich absolut nicht benötigen.
 
  • Gefällt mir
Reaktionen: RalphS
Discovery_1 schrieb:
Kapitalismus und Nachhaltigkeit wird nie funktionieren. Wo soll denn da noch der Wachstum herkommen, bei dem Wirtschaftssystem wo eben alles auf ewiges Wachstum ausgelegt ist und wo der Kapitalismus für die meisten Menschen heute zur Ersatz-Religion geworden ist
Und warum war dann dann beispielsweise die DDR so ein großer Klimasünder? Siehe: https://www.faz.net/aktuell/politik...mweltschaeden-der-ddr-industrie-13766763.html

Und natürlich kann Kapitalismus und Nachhaltigkeit funktionieren, z.b. mit CO2 Preisen. Durch die Extrakosten gibt es ein Anreizesystem diese zu vermeiden und so andere, nachhaltigere Verfahren zu nutzen.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen, Xul, begin_prog und eine weitere Person
Rassnahr schrieb:
(Allerdings war es hier durch file-system corruption)

Ja. Ich denke, das ist ein anderes Thema und betrifft eher File-Systeme auf Massenspeichern. Da wird Paritätsprüfung/Fehlerkorrektur in der einen oder anderen Form ja auch schon ewig praktiziert.

ECC im RAM würde nur dann gegen File Corruption helfen, wenn diese großen, wichtigen Datenmengen über längere Zeit im Arbeitsspeicher gehalten würden, ohne Redundanz oder Backup auf Massenspeichern. Es mag solche Anwendungsfälle geben, aber hoffentlich wird auf solchen Servern oder Workstations schon jetzt auf ECC-RAM gesetzt.

Das schlimmste, was auf Consumer-PCs passieren kann, ist wohl wirklich gelegentliche Instabilität durch einzelne, kippende Bits, aber das scheint bei der aktuellen Speichertechnik kein so großes Problem darzustellen, trotz immer größerer Kapazitäten.

Was Torvalds zu ärgern scheint ist, dass man ECC-Speicher für Profi-Anwendungen, wo er gebraucht wird, ziemlich teuer bezahlen muss. Die Schuld dafür gibt er Intel, weil die dieses Feature für den Consumer-Markt nicht unterstützen und deswegen die Preise für Profi-Komponenten mit ECC-Unterstützung durch kleine Stückzhalen hoch bleiben.

Ob es der richtige Ansatz ist, ECC in den Consumer-Markt zu pressen, wo es eher nicht gebraucht wird, damit es billiger für die professionellen Anwender wird, die es wirklich brauchen, darüber kann man streiten.(Optimalerweise aber etwas weniger patzig, als Torvalds. 😉)
 
  • Gefällt mir
Reaktionen: PcFliege, floTTes und JustAnotherTux
also: überall da, wo die hsardware ecc kann, verwende ich es.
 
  • Gefällt mir
Reaktionen: bitheat
die segmentierung bei intel ist schon lange sinnfrei... erst seit relativ kurzem hat ein core i3 auch mal turbo-boost. mal ist hyperthreading verfügbar, mal nicht. nicht alle cpus haben avx. was mich damals gewundert hat: warum hat ein i5-3570 vt-d, ein i5-3570k aber nicht? ebenso aes-ni: seit 2010 verfügbar, aber ständig mit ausnahmen, erst 5 jahre später überall drin. bei amd dagegen in jeder kleinen cpu dabei. ecc-support ist da nur das i-tüpfelchen...

Herdware schrieb:
ECC im RAM würde nur dann gegen File Corruption helfen, wenn diese großen, wichtigen Datenmengen über längere Zeit im Arbeitsspeicher gehalten würden, ohne Redundanz oder Backup auf Massenspeichern. Es mag solche Anwendungsfälle geben, aber hoffentlich wird auf solchen Servern oder Workstations schon jetzt auf ECC-RAM gesetzt.
das ist ein ganz normaler anwendungsfall bei storage-system mit zfs und deduplication (~5GB ram pro 1TB storage). und da will man keine bitfehler im ram :)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mibbio, lasbo, floTTes und 6 andere
Uskok1530 schrieb:
ECC kann aber keinen Schutz bieten wenn mehrere Bits zeitgleich gekippt werden, deswegen ist der ganze Artikel von Torvald sagen wir es mal "populistisch" und vorbei an jeglicher Realität und auch der neuen Realität mit DDR5. On-Die ECC Controller macht viel mehr Sinn als es über die ganze Kette DIMM -> MB -> CPU zu schleifen.

Oder anders gesagt: mit DDR5 würde ich darauf wetten, dass ECC in Zukunft mit einen On-Die ECC Controller abläuft und das System nur noch logt auch im Server Umfeld und der CPU Support für ECC Korrektur verschwinden wird.

So ein Rant scheint mir auch ein wenig übertrieben.

Neben der ECC Abwicklung innerhalb der Speicherchips oder der Ram-Module, die natürlich dann die Übetragung zwischen CPU und Modul nicht mehr absichern würden, könnte man ja auch durchaus mal die Frage stellen ob nicht eine variable Absicherung, Speicherfehlerentdeckung und Korrektur bzw. Redundanz je nach persönlichem Bedarf, gezielt in die Software hinein"kompiliert" werden könnte .. wenn einem das wirklich superwichtig erscheint. Wer weiß - vielleicht kann man da ja sogar Methoden ersinnen die Softwarefehler oder Angriffe mit absichert ..

Es gibt da viele Nasen an die man sich selber fassen könnte.
 
Zuletzt bearbeitet:
Zurück
Oben