Microcode-Patches gegen CPU-Lücken nicht unbedingt eine gute Idee

[o1] tapo am 18.04. 11:38
Hmm, also wenn ich das richtig verstehe gibt es aber 2 Arten von Microcode-Updates:
- welche die über das Betriebssystem geladen werden ("einfach" das OS neu installieren wie oben gesagt)
- welche die im BIOS/UEFI eingespielt werden, also wäre hier ein DualBIOS angebracht oder man baut einen anderen Prozessor ein und macht ein Downgrade der BIOS/UEFI-Version.

Also ein Unbrauchbr sehe ich da noch nicht (außer evtl bei geschlossenen Systemen wie Smartphone, Tablet, ... bei wichtigen Systemen wie Server eher weniger, zumindest in Rechenzentren wo Backup-Server vorhanden sein sollten und mit denen die nötigen Arbeiten realisiert werden könnten.
Bei Privatrechnern wäre das ggf. möglich indem man (wenn man nicht gerade ein passendes Ersatzteil hat) zum nächsten Technik-Laden des Vertrauens geht.
[re:1] dudelsack am 18.04. 11:50
+4 -1
@tapo: Verstehe von dem Thema wenig, komme da nur mit Logik weiter. Und was dieser Professor sagt, klingt sehr einleuchtend. Ich bin sicher, er hat Recht.

Ich glaube erstens nicht, dass Rechenzentren ein Backup für ihre komplette Hardware haben. Das wäre doch sehr teuer? Ich tippe einfach mal, dass sie irgendwas mit 20% einfach so ersetzen können, aber vermutlich handelt es sich da vor allem um Festplatten.

Und wenn plötzlich 1000000 CPUs abrauchen, wirst du bei deinem Händler des Vertrauens kaum mehr eine neue CPU finden!
Der Server Betreiber ebenso...
[re:1] tapo am 18.04. 14:53
+ -2
@dudelsack: Mein Kommentar wurde nicht verstanden...
"bei deinem Händler des Vertrauens" -> für Privatpersonen, also keine 1 Mio Prozessoren

"dass Rechenzentren ein Backup für ihre komplette Hardware haben." -> Niemand hat von KOmpletter Hardware gesprochen, es geht darum, dass sobald ein Server/Prozessor ausfällt, dass für diesen ein Backupserver (Repository) einspringt, während dieser Backupserver läuft kann das Problem behoben werden (ggf. Ersatzteil).
Wenn natürlich millionen von Prozessoren absolut zeitgleich funktionsunfähig werden ist es klar, dass dieses Vorgehen nicht funktionieren kann, aber zumindest im Winfuture-Artikel war nicht von zeitgleich die Rede.
[re:1] dudelsack am 18.04. 17:52
+2 -1
@tapo: doch wurde schon verstanden. Steht ja klar im artikel: kommt dieses böse update, sind alle CPUs im Arsch.
Und das natürlich relativ zeitgleich, da Updates nunmal gleichzeitig an sehr sehr viele Hardware ausgeliefert wird. Ausser, man macht es in Wellen.
Wie auch immer
[re:1] tapo am 18.04. 21:03
+1 -
@dudelsack: Jeder vernünftige Administrator wird kein Update und schon garnicht dieser Art zeitgleich auf allen Systemen verteilen sondern erst auf einer Teststellung ausprobieren. Wenn natürlich in allen Updates steht, dass am 01. April 2020 der CPU durchbrennen soll ist das dadurch nicht testbar, aber sowas wäre ja schon sehr dämlich.
[re:2] sLiveX am 18.04. 12:20
+9 -1
@tapo: Nein, wenn ich mich nicht irre, wird bei Microcode-Updates das komplett unabhängige "Betriebssystem" des Prozessors upgedatet. Das hat mit dem BIOS des Motherboards oder dem Betriebssystem auf der SSD/HDD erst mal nichts zu tun. Was er meint ist, wenn der Microcode einen unbrauchbar machenden Fehler hat, dann kannst du noch so sehr dein BIOS/UEFI umswitchen oder das Motherboard wechseln - der Prozessor lässt sich trotzdem nicht mehr initialisieren/starten. Da hilft nur noch den Prozessor zu wechseln.
[re:1] tapo am 18.04. 14:49
+1 -2
@sLiveX:
https://www.heise.de/security/meldung/Spectre-Luecke-Microcode-Updates-nun-doch-als-Windows-Update-3985133.html
--> Updates per Microsoft-Update
--> Vergleich mit Updates in Linux
ergo Updates im Betriebssystem

https://www.golem.de/news/updates-wie-man-spectre-und-meltdown-loswird-1801-132125-4.html
--> "Der Microcode wird nicht dauerhaft auf der CPU abgelegt," und "Update für Windows-Nutzer auch vom UEFI bereitgestellt"
[re:3] inge70 am 18.04. 16:07
+3 -1
@tapo: Wenn dir durch das Microcode-Update der Chip/CPU abraucht, hilft dir auch kein DUAL-Bios mehr, denn damit bekommst du das Ding nicht mehr zum laufen.
UND es geht hierbei nicht nur um Server, sondern auch um die Millionen Nutzer daheim, die im Endeffekt dann auf ihrer defekten hardware sitzen bleiben bzw. neu anschaffen müssen, weil keiner die finanziellen Möglichkeiten privat hat, einen Hersteller dafür Regress zu nhemen. gerade bei etwas älterer hardware.
[o2] dudelsack am 18.04. 11:47
+5 -1
"Angesichts dessen, dass Angriffe über Bugs in der Hardware aufgrund ihrer Komplexität doch eher extrem selten sind, sollte man Änderungen am Microcode nur sehr selten und mit viel Bedacht herausgeben. "

MEINE REDE!
[re:1] lasnik am 18.04. 13:07
+1 -1
@dudelsack: zzt noch nicht aber das kann sich ja auch andern!
[o3] KnolleJupp am 18.04. 11:50
+4 -5
Er redet von Meltdown/Spectre und irgendwie hat der Mann die Funktionsweise von Microcode-Updates nicht wirklich verstanden! Denn der Microcode ist fest und unveränderlich in eine CPU einprogrammiert. Seit dem Intel Pentium Pro gibt es aber zusätzlich einen kleinen "Flash"-Speicher in den CPUs, in den eine aktuellere Microcode-Version geladen werden kann beim Systemstart. Entweder liegt dieses Update im BIOS/UEFI vor und wird von dort aus in die CPU geladen oder es wird in einer sehr frühen Phase des Boot-Vorgangs vom Betriebssystem in die CPU geladen. Das spielt keine Rolle. Schaltet man den Rechner aus, verliert dieser Flash-Speicher seine Daten, ähnlich wie beim Arbeitsspeicher. Das Microcode-Update muss also bei jedem Boot-Vorgang wieder neu in die CPU geladen werden! Ansonsten wird eben die ab Werk fest einprogrammierte Version genutzt. Deshalb kann man eine CPU auf diesem Wege nicht dauerhaft zerstören, es sei denn das der Microcode selber derart gravierende Fehler enthält das er die CPU-Hardware zerstören könnte, sobald er einmal geladen wurde.
[re:1] dudelsack am 18.04. 11:51
+2 -1
@KnolleJupp: Ich dachte auch, dass es so funktioniert. Aber der Typ wird ja wohl Recht haben? Hm...
[re:1] KnolleJupp am 18.04. 11:57
+5 -2
@dudelsack: "Hier ist es dann einfach nicht mehr möglich, nochmal eine frühere Software-Version einzuspielen." - Diese Aussage ist völliger Unsinn, da der ab Werk einprogrammierte Microcode, mit dem die CPU definitiv läuft auch wenn dieser evtl. Sicherheitslücken enthält, zu keinem Zeitpunkt und durch keinen Patch verändert werden kann! Die CPU würde nur automatisch eine neuere Version in diesem Flash-Speicher nutzen, sobald dort etwas hineingeladen wird. Auch diese Möglichkeit stellt letztlich eine Sicherheitslücke dar. "So könne es durchaus passieren, dass man mit einem Patch einen weiteren Fehler in die Chips einbaut, der dann aber erst unter bestimmten Voraussetzungen Wirkung entfaltet." - Diese Aussage ist allerdings richtig.
[re:1] max06.net am 18.04. 12:09
+2 -6
@KnolleJupp: Also ich habe bereits Microcode-Updates in Intel-CPUs geflasht. Und zwar permanent. Mit "unveränderlich" wäre ich hier also vorsichtig...
[re:1] KnolleJupp am 18.04. 12:15
+6 -1
@max06.net: Und wie willst du das gemacht haben? Das geht nämlich nicht! Weder bei Intel, noch bei AMD. Jedenfalls nicht irreversibel, da neuerer Microcode den ab Werk vorhandenen nicht ersetzt und nicht dauerhaft ersetzen kann, sondern nur zusätzlich vorliegt. Die CPU guckt nur ob eine neuere Version vorliegt. Ja: Dann nutze ich diese. Nein: Dann nutze ich meine eigene. Sobald der Rechner ausgeschaltet wird, ist das Microcode-Update wieder gelöscht. Es muss bei jedem Start des Rechners wieder neu vom BIOS/UEFI oder Betriebssystem in die CPU geladen werden.
[re:2] max06.net am 18.04. 12:19
+3 -6
@KnolleJupp: Hast du Beweise für deine Behauptungen?

Ich habe im Rahmen meiner Tätigkeiten für einen PC-Hersteller Microcode-Updates geflasht.
[re:3] KnolleJupp am 18.04. 12:35
+3 -1
@max06.net: :-) Das ist halt so. Kann man auch nachlesen. Bei Intel gibt es diese Möglichkeit seit dem P6 (als Konsequenz aus dem FDIV-Bug, bei dem Gleitkommaberechnungen fehlerhaft waren). Bei AMD kam diese Möglichkeit erst deutlich später, ab dem K10. Bei der Initialisierung der CPU, genauer: bevor der L2-Cache initialisiert wird, kann ein Microcode-Update in einen dafür bereitstehenden Flash-Speicher geladen werden. Der ab Werk einprogrammierte Microcode liegt in einem unveränderlichen ROM. Dieser kann nicht verändert werden und solange kein Update geladen wird, wird dieser auch brav benutzt. Das gilt nicht nur für diese alten CPUs, sondern genauso auch für die aktuellsten. An dieser Handhabung hat sich seit Einführung dieser Möglichkeit nichts verändert. Es mag andere Prozessoren geben, bei denen das geht. Ich weiß z.B. nicht wie es bei ARM CPUs aussieht.
[re:4] 1ST1 am 18.04. 13:23
+7 -3
@KnolleJupp: @max06.net : Alles falsch. Das microcode-Update bleibt nicht permanent in der CPU. Nach Strom weg oder Reset ist es wieder weg. Du wirst wohl ein BIOS-Update in dem Rechner eingeflasht haben, welches ein neues Microcode-Update enthält, und dieses bei jedem BIOS-Start in die CPU überträgt. Das ist was anderes, aber der Effekt ist mehr oder weniger der selbe.
[re:2] skyjagger am 18.04. 12:49
+5 -1
@KnolleJupp: Das ist nicht ganz richtig. Der Flash liegt direkt in der CPU und wird von daher zuerst gelesen. Wenn da etwas falsches codiert wurde, kommt die CPU nicht mehr auf die Schnittstellen zum BIOS um von dort irgendetwas zu laden. Von daher hat der gute Mann leider Recht...
[re:1] KnolleJupp am 18.04. 12:53
+1 -2
@skyjagger: Wie ich bereits schieb - auch diese Möglichkeit stellt letztlich eine Sicherheitslücke dar - stellt die Möglichkeit eines Microcode-Updates durchaus eine grundsätzliche Sicherheitslücke dar, in dem man beispielsweise absichtlich ein fehlerhaftes Update einspielt, dass Schaden anrichten könnte. Ich wollte nur klar stellen das man den ab Werk einprogrammierten Microcode nicht dauerhaft überschreiben kann.
[re:1] skyjagger am 18.04. 13:03
+2 -2
@KnolleJupp: Klar stellt jede Möglichkeit ein Risiko dar. Aber du unterliegst einem kleinem Irrglaube, der Flashspeicher in der CPU ist "reset" fest, das heißt, dass die CPU erst mittels spezieller Anweisung dazu gebracht wird den Speicher auf "schreibbar" zu schalten. Wenn die CPU nun aber nicht mehr sauber arbeiten kann, wird auch dieser Modus nicht so einfach zu erreichen sein. Ich könnte mir vorstellen das man diesen Fehler zwar noch mittels Programmiermodul beheben könnte, aber wer hat schon ein solches und dann die entsprechenden Kenntnisse dies zu tun. Das könnte wohl nur Intel selber. Und bei milliarden von CPUs die im Einsatz sind, viel Spaß :)
[re:2] dudelsack am 18.04. 12:58
+3 -
@skyjagger: Das klingt logisch. Man kann also, wenn so ein Fehler vorliegt und die CPU den fehlerhaften Code aus dem Flash liest, die CPU nicht aktiv dazu zwingen, einen anderen, fehlerfreien (bzw den originalen) Code zu nutzen?
[re:1] skyjagger am 18.04. 13:00
+3 -1
@dudelsack: Nein kann man leider nicht. Da die CPU beim initialisieren immer erst in den Flash schaut. Wenn da was steht, was so nicht funktionieren kann, dann ist es duster.
[re:1] dudelsack am 18.04. 13:01
+ -3
@skyjagger: Aber die Aussage, dass der Flash beim herunterfahren seine Daten verliert, und diese beim Hochfahren neu eingespielt werden, ist also falsch? Ich meine nämlich schon, dass es so ist. Aber habe nicht wirklich Ahnung.
[re:2] skyjagger am 18.04. 13:04
+2 -1
@dudelsack: Diese Aussage ist schlicht falsch. Es ist kein RAM sondern Flash, sonst könntest du ja zum Beispiel auf deiner Speicherkarte im Handy auch keine Daten dauerhaft ablegen.
[re:3] KnolleJupp am 18.04. 13:11
+4 -2
@skyjagger: Es tut mir ja furchtbar leid, aber dieser "Flash"-Speicher ist kein Flash-Speicher. Das ist keine "SD-Karte" im Handy. Ich habe den Begriff nur der Einfachheit wegen gewählt. Exakt ist es SRAM, dieser ist flüchtig und verliert seine Daten wenn der Strom weg ist.
[re:4] 1ST1 am 18.04. 13:24
+2 -2
@skyjagger: Und was hat jetzt die Handy-Speicherkarte mit dem Microcode-Update-RAM in einer CPU zu tun?
[re:5] skyjagger am 18.04. 14:38
+ -2
@1ST1: Dies war nur als Vergleich gedacht. Weil die Funktion ähnlich ist. Aber auch nur ähnlich.
[re:6] skyjagger am 18.04. 14:40
+1 -1
@KnolleJupp: Es gibt einen EEPROM Speicherbereich in der CPU welcher nachträglich beschrieben werden kann. Dieser ist eben nicht flüchtig und behält seine Werte auch nach dem Stromausfall/reset.
[re:7] KnolleJupp am 18.04. 14:51
+1 -1
@skyjagger: Vielleicht liest du dich einfach noch mal ein bisschen genauer ein, wie das mit den Microcodes tatsächlich funktioniert. Mir ist es egal ob du mir glaubst oder nicht, denn es kommt nur darauf an wie es eben tatsächlich ist. Das ist SRAM (jedenfalls bei Intel und AMD), der volatil, also flüchtig ist, der aber anders als DRAM (z.B. Arbeitsspeicher) kein ständiges Auffrischen der enthaltenen Daten benötigt. Wenn Strom weg, dann Daten weg! Himmel Herrgott Sakament... ;-) Der ab Werk mitgelieferte Microcode liegt dagegen in einem Read-Only-Speicher und kann deshalb nicht überschrieben werden. Sicher kann es passieren das ein fehlerhaftes Update die CPU unbrauchbar macht. Das geht aber nur, wenn der angerichtete Schaden dann so groß ist und die Hardware betrifft, dass er auch nach einem Neustart ohne das Update noch vorhanden ist. Das wäre allerdings in den letzten 20 Jahren, solange wie es diese Möglichkeit eines Updates eben gibt, noch nie vorgekommen.
[re:2] KnolleJupp am 18.04. 13:09
+3 -
@dudelsack: Richtig. Wurde dort beim Systemstart ein Microcode hineingeladen, wird dieser auch benutzt, egal ob dieser bewusst oder unbewusst fehlerhaft ist.
[o4] Blackspeed am 18.04. 12:53
+3 -2
Mit Argumenten solcher Leute schlage ich mich im Betrieb regelmäßig rum, um gegen die bloß-nie-Patchen Politik anzukämpfen.
[re:1] Stratus-fan am 18.04. 13:15
+2 -2
@Blackspeed: Vielleicht weil Du und andere nicht differenziert genug lesen? ;) Die hier vorgebrachte Kritik ist ja durchaus berechtigt. Vor allem da die Patches ja tatsächlich fehlerhaft waren.

Es wird aber auch gesagt, dass fehlerhaftes SW-Patches längst nicht so problematisch sind. Du und deine Kollegen sollten beim Lesen also einfach etwas genauer darauf achten wovon die Rede ist. Dann hast Du weniger zu diskutieren und musst dich auch nicht unnötig über etwas aufregen, was gar nicht gesagt wurde^^
[o5] 1ST1 am 18.04. 13:11
+3 -4
So ein Quatsch... Strom weg, Microcode-Update auch weg... Das Ding läuft bis zum nächsten Update mit dem Microcode, den es in der fabrik einst bekommen hat.
[re:1] Karmageddon am 18.04. 13:17
+3 -
@1ST1: Ohne Strom läuft "das Ding" überhaupt nicht.
[re:1] 1ST1 am 18.04. 13:25
+2 -3
@Karmageddon: Ach komm...???
[re:2] tapo am 18.04. 15:04
+ -2
@1ST1: endlich mal jemand der das richtig sieht (auch wenn etwas überspitzt) aber hier bei Winfuture haben diverse Leute irgendwie keine Ahnung bzw. die die es haben wollen anscheinend nicht "Bewerten"

Mit überspitzt meine ichm, dass das Microcode-Update bestehen bleibt wenn der Strom weg ist, nur halt nicht im Prozessor, sondern im BIOS/UEFI/CMOS bzw. den von diesen verwalteten Speicherblöcken.
Das ein Microcode-Update über ein Update des BIOS/UEFI kommt kann man schön bei einigen Mainboard-Herstellern sehen, mit diesen werden z.B. neuere Prozessoren auf Mainboards erst ermöglicht. Aktualisierungen jedoch, also da wo Prozessoren grundsätzlich bereits lauffähig sind können Microcode-Updaes auch über Updates im Betriebssystem erhalten.
Beispiel Microcode-Update bei einem Mainbaord:
http://www.asrock.com/mb/AMD/X370%20Killer%20SLIac/#BIOS
--> Update AMD AGESA: https://de.wikipedia.org/wiki/AMD_Generic_Encapsulated_Software_Architecture
[o6] KarstenS am 18.04. 14:37
+5 -1
Ich glaube einige der Kommentatoren haben eine etwas falsche Vorstellung davon, wie genau ein Microcode Update funktioniert.

In der CPU ist kein Flash Speicher, welcher sich überschreiben lässt. Würde das so funktionieren, gäbe es auch ein Update Tool für CPUs.

Der aktualisierte Microcode muss bei jedem Systemstart neu geladen werden. Entweder vom Betriebssystem oder vom BIOS. Nur deswegen gibt es diese Updatepfade überhaupt.

Ein Rollback ist daher grundsätzlich relativ einfach möglich.

Was der Sorgenträger vermutlich meint ist, dass fehlerhafter Code möglicherweise zum Durchbrennen von Transistoren führen kann. Das wäre dann tatsächlich ein Defekt, welcher nicht mehr umkehrbar ist.
[re:1] tapo am 18.04. 15:05
+1 -
@KarstenS: danke, plus von mir, siehe auch mein re:2 zu o5 ;)
sowie o1
[re:2] KnolleJupp am 18.04. 15:13
+2 -
@KarstenS: Ich habe mir bei meinen Erklärungen in der Tat keinen Gefallen getan das Wort "Flash" zu benutzen. ;-) Ich wollte es nur laienhaft ausdrücken.
[o7] lalalala am 18.04. 17:24
+1 -2
ne, ich hab schon lang alle update leitungen zu allen Herstellern gekappt. Ich hab das schon so oft hier erwähnt. Meltown & Spectre patches sind auf meinen 8 PC's nicht zu finden !!
[o8] AWolf am 18.04. 17:41
+2 -1
Erschreckend, zu sehen, daß es möglich ist, daß sich Microcode- Updates einfach ohne Zustimmung des Anwenders verteilen lassen. Nicht auszudenken, wenn mit diesem Update ein Trojaner installierbar ist, der auf Knopfdruck irgend einer Regierung die Hardware aller PC einer Region schachmatt setzen kann. Server, Clients, Ladenkassen und eigentlich alles, was mit Computern zu tun hat.
[o9] 1ST1 am 06.02. 08:54
+ -
Der Artikel ist einfach nur Bullshit. Denn Microcode-Updates sind ja nichts dauerhaftes, die müssen nach jedem Powercycle und CPU-Reset neu aus dem BIOS oder per Softwareupdate aus dem Betriebssystem wieder neu in die CPU geladen werden. Denn Microcode-Updates werden in der CPU in flüchtigem Speicher (normales S- oder DRAM) abgelegt. Käme es tatsächlich mal zu einem fehlerhaften Microcode-Update, würde es reichen, die CPU zu resetten und ein anderes/älteres BIOS zu flashen und das Microcodeupdate im Betriebssystem wieder zurückzunehmen. Die CPU läuft durch den Reset automatisch erstmal wieder mit dem Microcode, der bei der Herstellung der CPU in das Maskenrom geschrieben wurde. Schade, dass jemand dessen erster Buchstabe in "RSA" verewigt ist, sich für so eine dumme Aussage hergibt.
oder

Zugangsdaten vergessen?

Jetzt kostenlos Registrieren!
Desktop-Version anzeigen
Hoch © 2022 WinFuture Impressum Datenschutz Cookies