Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

[rendegast]

Hundertprozentige Sicherheit

ist wie "gültige Erlaubnis".
Beide Adjektive sind blafasel.

[hikaru]

Man bedenke: Bevor eine der beiden Sicherheitslücken ausgenutzt werden kann, müsste es erst einmal eine Malware auf das betreffende Computersystem schaffen bzw selbiges auf irgendeine Art kompromittiert werden. Zumindest unter Debian bzw Linux (und natürlich auch andere unixoide Systeme) halte ich es für eher unwahrscheinlich, dass es zukünftig im nennenswerten Maße Schadsoftware geben wird, welche Meltdown bzw Spectre gezielt ausnutzt.

Im Prinzip kann jede Webseite die du im Browser aufrufst einen Spectre-Angriff fahren.

Wie lange wird es denn letztendlich dauern, bis die Fehler ausgemerzt sind? Möglicherweise noch ein paar Jahre, oder?

Auf derzeitig betroffener Hardware wird Spectre nie wirklich ausgemerzt sein, egal was da noch für Updates kommen mögen.
Neue Hardware könnte man so designen, dass sie nicht gegen Spectre anfällig ist. Dafür muss man aber vermutlich sehr früh im Designzyklus ansetzen, so dass ich nicht erwarte, dass momentan bereits in Entwicklung befindliche Hardware Spectre-immun sein wird, wenn sie es nicht auch ohne die Enthüllungen eh gewesen wäre.

Um nicht auf eine Lösung hoffen zu müssen und für die Zeit gewappnet zu sein wenn Debian den i686-Support einstellt habe ich schon Ausschau nach alten In-Order-64bit-Atom-Systemen gehalten um sie in Zukunft als dedizierte Banking-Systeme zu betreiben. Aber der Markt ist da inzwischen recht leergefegt. Irgendwas mit D525 wäre schön, vielleicht kann ich meinem Kollegen meinen alten ZBox-HTPC wieder abluchsen.

Benchmarks von Intel, max. -10% , SSDS noch mehr betroffen

https://www.heise.de/newsticker/meldung ... 38747.html

Ich konnte zumindest auf meinen Merom- und Penryn-Systemen (mit SSDs) am Wochenende nach Einspielen des KPTI-Kernels feststellen, dass insbesondere der Firefox-Start direkt nach dem Booten bis hin zum Laden der ersten Webseite deutlich länger dauerte. Wenn es dazu noch Rödelgeräusche gegeben hätte, dann hätte ich glatt nostalgische Gefühle an 90er-Jahre-HDDs entwickeln können.

STRATO

blafasel.

Gute Zusammenfassung.

[TuxPeter]

... und die wandernde Kröte ist auch dann platt, wenn der SUV sie mit 30 anstatt mit 50 km/h überrollt.

Wir sollten nicht vergessen, dass die Geschw.beschränkung ja nicht zur Rettung der Kröte eingeführt wurde, sondern damit das überteuerte Fahrzeug nicht auf der plattgefahrenen Kröte ausrutscht und in den Graben reinrammelt.

Und nun dürft Ihr raten, wer ist die Kröte und wer ist das SUV.

[BenutzerGa4gooPh]

Meine CPU ist in diesem Fall ein Core-i5-3450 (Ivy Bridge vom 23. Apr. 2012), für die es (noch) keine Microcode-Updates von Intel gibt. Ob es jemals Updates geben wird, ist unklar, Intel liefert im Moment nur Micorcodes für CPUs, die maximal 5 Jahre alt sind, also Hasswell und neuer.

Für Haswell neuer Mikrocode? intel-microcode und iucode-tool sind installiert.

Code: Alles auswählen

lscpu | grep name
Model name:            Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz
uname -a
Linux laptop 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux
dmesg | grep -i iso
[    0.000000] Kernel/User page tables isolation: enabled
dmesg | grep -i micro
[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
[    0.725280] microcode: sig=0x306c3, pf=0x10, revision=0x22
[    0.725561] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Daran liegt es nicht:

Code: Alles auswählen

apt-get install intel-microcode iucode-tool
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
iucode-tool ist schon die neueste Version (2.1.1-1).
intel-microcode ist schon die neueste Version (3.20170707.1~deb9u1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Code: Alles auswählen

apt show intel-microcode
Package: intel-microcode
Version: 3.20170707.1~deb9u1
...

Jan. 2017 ist ne Weile her, Revisionsnummern gleich. Oder verstehe ich die dmesg-Ausgabe nicht?

[Dogge]

Ist doch Juli 2017.

[Colttt]

Nur so aus neugier, sind den (Open)Power und Sparc-Prozessoren auch betroffen?

Wenn nicht, ob's da jetzt nen Run drauf gibt?

ja sind sie..
https://www.heise.de/newsticker/meldung ... 38749.html

(ja ich weiss ich antworte mir selbst)

[dufty2]

Für Haswell neuer Mikrocode? intel-microcode und iucode-tool sind installiert.

Jan. 2017 ist ne Weile her, Revisionsnummern gleich. Oder verstehe ich die dmesg-Ausgabe nicht?

Diese Intel-Seite verwirrt doch ziemlich viele Leute.

Du benutzt Stretch (stable) und die aktuellste intel-microcode.deb ist 3.20170707.1~deb9u1 für amd64.
So weit, so gut. In Backports gäbe es noch 3.20171117.1~bpo9+1.
Das reicht aber immer noch nicht, denn

Code: Alles auswählen

$ grep 0x000306c3 changelog 
    sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
    sig 0x000306c3, pf_mask 0x32, 2017-01-27, rev 0x0022, size 22528
    sig 0x000306c3, pf_mask 0x32, 2016-03-16, rev 0x0020, size 22528
    sig 0x000306c3, pf_mask 0x32, 2015-08-13, rev 0x001e, size 21504
    sig 0x000306c3, pf_mask 0x32, 2014-07-03, rev 0x001c, size 21504
    sig 0x000306c3, pf_mask 0x32, 2014-05-23, rev 0x001a, size 20480
    sig 0x000306c3, pf_mask 0x32, 2013-08-16, rev 0x0017, size 20480
    sig 0x000306c3, pf_mask 0x32, 2013-08-07, rev 0x0016, size 20480
    sig 0x000306c3, pf_mask 0x32, 2013-07-02, rev 0x0012, size 19456

Also bräuchte man 3.20171215.1 aus buster (testing) oder
3.20180108.1 aus sid (unstable).

[BenutzerGa4gooPh]

In Backports gäbe es noch 3.20171117.1~bpo9+1.
Das reicht aber immer noch nicht, denn
...
Also bräuchte man 3.20171215.1 aus buster (testing) oder
3.20180108.1 aus sid (unstable).

Passt dann aber nicht unbedingt zu einem Backport-Kernel. Na ja, bissel abwarten, Franken-Debian will ich nicht. Allerdings sind mittlerweile die Angriffsszenarien veröffentlicht. Was wohl Zeit gehabt hätte, bis der letzte Patch fertig ist.
(BSD wurde diesbezüglich "zeitnah" im wahrsten Sinne des Wortes informiert.)

[MSfree]

Passt dann aber nicht unbedingt zu einem Backport-Kernel.

Um Nochmal der Verwirrung Klarheit zu verschaffen:
Die aktuellen Kernel unterstützen jetzt Kernel/User page tables isolation, was gegen Meltdown immunisiert.

Der aktualisierte CPU-Microcode hilft gegen Spectre-Angriffe, wenn auch nicht vollständig. Der Microcode ist völlig unabhängig vom Kernel, solange der nur irgendwie in die CPU geladen wird, ist der aktiv. Das Laden kann auch über BIOS/UEFI geschehen.

[ingo2]

... Intel liefert im Moment nur Micorcodes für CPUs, die maximal 5 Jahre alt sind, also Hasswell und neuer.

Ist eventuell sogar eine Masche des Marketings:

Die machen der Öffentlickkeit weiß, es wären damit die Sicherheitslöcher aller CPU's ab Haswell gefixt und damit indirekt "wer eine noch ältere CPU nutzt möge doch gefälligst die neuestren Intel-CPU's kaufen - damit ist dann alles sicher". Anders werden sie doch ihre verwanzte Hardware nicht los.

In Wirklichkeit haben sie ein Bischen was getan - nämlich ein paar Firmware-Updates released, aber den Löwenanteil der Arbeit anderen, nämlich den OS- und Software-Herstellern aufgehalst. Und die User sollen den Performance-Verlust einfach schlucken

Und damit ist das Problem der schrottigen CPU's mit Nichten beseitigt, sie sind nämlich allesamt nicht spezifikationsgerecht, was zumindest die page-table Isolation zwischen Ring 0 (kernel space) und Ring 3 (Userland) betrifft und zu "privilage escalation" führt.

So viel ich die Funktion der Firmware-Updates verstanden habe, liefern sie nur ein paar Befehle/Funktionen, mit denen die Software-Entwickler dann bei Bedarf die Fehlspekulation der CPU's unterbinden können. Damit wird auch das Problem (die CPU verwahrt die nämlich auch nicht sicher) nicht gefixt, sondern nur abgewälzt.

[NAB]

Letztendlich ist Supermicro genauso darauf angewiesen, dass Intel in die Hufe kommt, wie jeder andere auch. Bevor also Intel etwas zu Microcodes für Nehalem, Sandy und Ivy Bridge verkündet, ist alles was andere dazu sagen Schall und Rauch.

An der Spekulation über die Interpretationsmöglichkeiten einzelner Worte mag ich mich nun nicht beteiligen, aber um deine Bedenken mal auf den Punkt zu bringen: stimmt, auffällig in der Ankündigung von Supermicro ist, dass da jegliche Angabe fehlt, wann solche BIOS-Updates denn zu erwarten wären. Das mag sich durchaus bis zum St.Nimmerleinstag ziehen, zumal Intel ja schon ein halbes Jahr Zeit hatte, die jetzt tröpfelnden Microcode-Updates herauszubringen. Intels Leistung ist hier unter aller Sau, keine Frage.

Auf der anderen Seite ist Supermicro aber genau die richtige Firma um Intel den Arsch wegzuklagen, wenn Intel nicht liefert. Die haben teure Servermainboards und langlaufende Supportverträge, hätten also wirkliche Schäden geltend zu machen gegen Intel.

Und was diese Microcode-Diskussion generell angeht:
Soweit ich das verstanden habe, gibt es zwei mögliche Ansätze gegen Spectre:
1) Intels "IBRS", also gewissermaßen die Einführung neuer CPU-Befehle. Dazu ist ein Microcode-Update für jeden Prozessor erforderlich - und ein Neukompilieren sämtlicher Software.
2) Googles "Retpoline". Dieser Ansatz funktioniert rein in Software, erfordert aber auch ein vollständiges Neukompilieren. Nunja, er würde rein in Software funktionieren, wenn Intel nicht ab Skylake (oder Broadwell?) was versaut hätte. Prozessoren ab Skylake bräuchten also auch hier ein Microcode-Update. Das kriegen sie aber auch.
Vergleiche:
https://www.heise.de/newsticker/meldung ... 36956.html
https://security.googleblog.com/2018/01 ... cpu_4.html
https://stackoverflow.com/questions/480 ... es-it-work

Ich sehe für ältere Prozessoren also so oder so nicht schwarz. Nur wie lange der Mist dauert und was man bis dahin macht weiß ich natürlich auch nicht.

Aber sorry dass ich das jetzt bring - gliech nachdem ich da draufgeklickt hatte, habe ich mich gefragt, ob ich eigentlich bescheuert bin, einfach mal auf einen mir völlig unbekannten und nicht einschätzbaren Link zu klicken, bloß weil er im DF steht?

Siehst du ... da haben wir schon den ersten Unterschied. Als ich da drauf geklickt habe, passierte erst mal gar nichts. Warum?
Ich habe "NoScript" für Firefox installiert, das verhindert erst mal pauschal die Ausführung von JavaScript. Dann habe ich nachgeguckt, was das Script überhaupt macht ... sah für mich harmlos aus ... und dann habe ich per NoScript die Ausführung erlaubt. Insbesondere für den Firefox ESR würde ich dir dringend ebenfalls zu NoScript raten, das verhindert schon mal den einfachsten Angriff über JavaScript. Auch für andere Browser ist irgendeine Script-Verhinderung so oder so dringend zu empfehlen.

Wichtige Passw. nicht per Browser speichern (die drei, vier wirklich wichtigen PWs hatte ich da sowieso nie)

Das hilft insbesondere gegen Spectre gar nichts. Spectre liest den Speicher des Browsers aus ... und wo landen die Passwörter, wenn du sie eingibst? Richtig ... im Speicher.

- Wenn geldwerte Transaktionen über den Browser stattfanden (Banking, Paypal, Ebay) den PC anschließend neu booten. (Oder reicht es, User ab/anzumelden, oder ist das sowieso Quatsch und egal?)

Danach? Davor wäre sinnvoller. Erst muss ja der Schadcode per Javascript gestartet werden, danach kann er dich belauschen. Es sollte reichen, nur den Browser neu zu starten und ihn nur exakt die Seite öffnen zu lassen, auf der du gerade die "geldwerten Transaktionen" durchführen willst. Diese Seite könnte zwar auch "gehackt" sein, aber dann haben die eh ein größeres Problem. Ein weiterer Neustart des Browsers danach könnte auch Sinn machen - ich habe keine Ahnung, wielange er Passwörter im Speicher hält. Und erwähnte ich NoScript schon?

Achtung: Diese Hinweise verhindern nur genau die Ausnutzung von Spectre im Browser per JavaScript, eben weil JavaScript ausgeschaltet oder eingegrenzt wird. Ansonsten ist die Kiste und der Browser gegenüber Spectre natürlich weiterhin sperrangelweit offen.

[TuxPeter]

Danke für Hinweis auf Noscript - habe ich jetzt installiert. Jetzt waren erst mal diverse kleinere Ecken im DF leer ...
Man merkt schon - ist nicht mein Hobby, mich mit diesen Seiten der Computerei zu befassen.

[inne]

Danke für Hinweis auf Noscript

Mit einmal wird die Welt ganz klein... *over-n-out*

[Animefreak79]

Man sollte doch sowieso immer einen Skriptblocker benutzen, der beispielsweise JavaScript auf den enstprechenden Websites deaktiviert. Ich nutze unter Chromium beispielsweise ScriptBlock.

[hikaru]

Auf der anderen Seite ist Supermicro aber genau die richtige Firma um Intel den Arsch wegzuklagen, wenn Intel nicht liefert. Die haben teure Servermainboards und langlaufende Supportverträge, hätten also wirkliche Schäden geltend zu machen gegen Intel.

Und diese Verträge sind so langanhaltend, dass Supermicro mit einem Prozess durchkäme, bevor ihre Verträge mit Intel über Nehalem auslaufen?
Anders sehe ich da nämlich keine Chance für Supermicro, denn die wären in dem Duell ganz klar der David.

Und was diese Microcode-Diskussion generell angeht:
Soweit ich das verstanden habe, gibt es zwei mögliche Ansätze gegen Spectre:
1) Intels "IBRS", also gewissermaßen die Einführung neuer CPU-Befehle. Dazu ist ein Microcode-Update für jeden Prozessor erforderlich - und ein Neukompilieren sämtlicher Software.
2) Googles "Retpoline". Dieser Ansatz funktioniert rein in Software, erfordert aber auch ein vollständiges Neukompilieren. Nunja, er würde rein in Software funktionieren, wenn Intel nicht ab Skylake (oder Broadwell?) was versaut hätte. Prozessoren ab Skylake bräuchten also auch hier ein Microcode-Update. Das kriegen sie aber auch.
Vergleiche:
https://www.heise.de/newsticker/meldung ... 36956.html
https://security.googleblog.com/2018/01 ... cpu_4.html
https://stackoverflow.com/questions/480 ... es-it-work

Die beiden Ansätze die du ansprichst helfen nur gegen Spectre Variante 2 (branch target injection: CVE-2017-5715), nicht gegen Variante 1 (bounds check bypass: CVE-2017-5753).
Variante 1 und 2 müssen auf verwundbarer Hardware in JEDEM Stück Software an JEDER potenziell gefährlichen Stelle behandelt werden. Genau das habe ich früher im Thread als Sisyphosarbeit bezeichnet und spätestens wenn da Begriffe wie "legacy" und "proprietär" in's Spiel kommen, dann sind wir uns wohl beide darüber einig, wie die Erfolgsaussichten sind. Leider haben wir nicht überall unter unserer Kontrolle, wann uns diese Begriffe begegnen.

[dufty2]

Die beiden Ansätze die du ansprichst helfen nur gegen Spectre Variante 2 (branch target injection: CVE-2017-5715), nicht gegen Variante 1 (bounds check bypass: CVE-2017-5753).

Yep, einfach mal das script-chen laufen lassen und schon ist mensch schlauer:

Code: Alles auswählen

# sh spectre-meltdown-checker.sh 
Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.12-2 (2018-01-06) x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 23 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer

Na ja, für einen Atom N450 passt's wohl auch nicht ganz, aber was soll's

[NAB]

Und diese Verträge sind so langanhaltend, dass Supermicro mit einem Prozess durchkäme, bevor ihre Verträge mit Intel über Nehalem auslaufen?
Anders sehe ich da nämlich keine Chance für Supermicro, denn die wären in dem Duell ganz klar der David.

Höm? In interne Verträge von Supermicro habe ich natürlich keinen Einblick, aber immerhin steht da "awaiting" und nicht "EOL". Aus irgendeinem Grund wollen sie also Support leisten und ich vermute keine philanthropischen Beweggründe. Und aus dem David kann schnell ein Goliath werden, wenn andere Firmen ihre Schäden bei Supermicro geltend machen und Supermicro diese an Intel weiterzureichen versucht ...

Die beiden Ansätze die du ansprichst helfen nur gegen Spectre Variante 2 (branch target injection: CVE-2017-5715), nicht gegen Variante 1 (bounds check bypass: CVE-2017-5753).
Variante 1 und 2 müssen auf verwundbarer Hardware in JEDEM Stück Software an JEDER potenziell gefährlichen Stelle behandelt werden. Genau das habe ich früher im Thread als Sisyphosarbeit bezeichnet und spätestens wenn da Begriffe wie "legacy" und "proprietär" in's Spiel kommen, dann sind wir uns wohl beide darüber einig, wie die Erfolgsaussichten sind.

Höm? Ich sprach einzig und alleine von den Chancen, ältere Prozessoren doch noch irgendwann wieder sicher betreiben zu können, also von der Hardware ... so als Kontrastprogramm zum "Möh, alles älter als Haswell muss in die Mülltonne". Nun kommst du mit der Software.

Ja, dass die Software an Spectre angepasst werden muss ist mir bekannt. Schlimm genug und blöd genug, ja. Ob das wirklich manuelle "Sisyphosarbeit" sein muss oder sich irgendwie automatisieren lässt, eventuell sogar bei proprietären Softwareschinken, das kann wohl im Moment noch niemand abschätzen. Aber ich wollte Spectre sicherlich nicht kleinreden.

[nudgegoonies]

Ich hatte es so verstanden, dass Intel nur CPUs der letzten 5 Jahre patched. Jetzt habe ich habe mir folgende Debianpakete mit den Microcodes von oldoldstable bis experimental für die Intel CPUs angesehen:

Code: Alles auswählen

intel-microcode_1.20150121.1
intel-microcode_3.20161104.1
intel-microcode_3.20170511.1
intel-microcode_3.20170707.1
intel-microcode_3.20171117.1
intel-microcode_3.20180108.1

Ich habe einen Q6600. Laut /proc/cpuinfo ist das family 6, model 15, stepping 11. In HEX also 06,0f,0b. Die Datei für meine CPU heißt also:

Code: Alles auswählen

/lib/firmware/intel-ucode/06-0f-0b

Alle Microcodes vor 2018 waren identisch:

Code: Alles auswählen

md5sum 06-0f-0b 
e19ab5b0f342fa6d14d3a48866eac6ed  06-0f-0b

Aber der von 8. Januar 2018:

Code: Alles auswählen

md5sum 06-0f-0b 
c2c4623aee49a3c35c39f66d01152098  06-0f-0b

Geschehen also doch noch Wunder, dass Intel eine 10 Jahre alte CPU patched? Ausprobiert habe ich das Paket noch nicht. Wenn, dann könnte ich über /proc/cpuinfo ja den Microcode Stand überprüfen. Vielleicht sollte ich damit aber auch warten, bis es wirklich in Stretch oder den Stretch Backports erscheint. Und wer weiß was noch kommt:
https://www.heise.de/newsticker/meldung ... 40326.html

[NAB]

https://www.heise.de/newsticker/meldung ... 40326.html

Ach du Scheiße ...

Hier übrigens die Originalaussage von Intel zu älteren Prozessoren:
https://newsroom.intel.com/news-release ... st-pledge/
"... as prioritized by our customers." ... so so. Wo darf man abstimmen?

AMD rührt sich inzwischen übrigens auch:
https://www.amd.com/en/corporate/speculative-execution
Da werden die Microcode Updates als "optional" bezeichnet weil sie wissen noch nicht so genau. Aber es sollen welche kommen.

[dufty2]

Ich habe einen Q6600. Laut /proc/cpuinfo ist das family 6, model 15, stepping 11. In HEX also 06,0f,0b. Die Datei für meine CPU heißt also:

Code: Alles auswählen

/lib/firmware/intel-ucode/06-0f-0b

Mmmh, also im source-file von Intel hat das ne andere md5sum:

Code: Alles auswählen

$ md5sum intel-ucode/06-0f-0b
4518fa18328a5c79ba6263ecd741b2c1  intel-ucode/06-0f-0b

Scheinbar wird das nochmals umgemodelt im .deb-file.

Falls ich es jetzt richtig interpretiert habe:

Code: Alles auswählen

$ grep 006fb changelog 
    sig 0x000006fb, pf_mask 0x20, 2010-10-03, rev 0x00ba, size 4096
    sig 0x000006fb, pf_mask 0x01, 2010-10-03, rev 0x00ba, size 4096
    sig 0x000006fb, pf_mask 0x04, 2010-10-03, rev 0x00bc, size 4096
    sig 0x000006fb, pf_mask 0x08, 2010-10-03, rev 0x00bb, size 4096
    sig 0x000006fb, pf_mask 0x10, 2010-10-03, rev 0x00ba, size 4096
    sig 0x000006fb, pf_mask 0x40, 2010-10-03, rev 0x00bc, size 4096
    sig 0x000006fb, pf_mask 0x80, 2010-10-03, rev 0x00ba, size 4096
    sig 0x000006fb, pf_mask 0x04, 2009-05-11, rev 0x00b9, size 4096
    sig 0x000006fb, pf_mask 0x08, 2009-04-28, rev 0x00b8, size 4096
    sig 0x000006fb, pf_mask 0x40, 2009-05-11, rev 0x00b9, size 4096
    sig 0x000006fb, pf_mask 0x80, 2007-07-13, rev 0x00b6, size 4096
    sig 0x000006fb, pf_mask 0x01, 2007-07-13, rev 0x00b6, size 4096
    sig 0x000006fb, pf_mask 0x04, 2007-08-06, rev 0x00b7, size 4096
    sig 0x000006fb, pf_mask 0x08, 2007-07-13, rev 0x00b6, size 4096
    sig 0x000006fb, pf_mask 0x10, 2007-07-13, rev 0x00b6, size 4096
    sig 0x000006fb, pf_mask 0x40, 2007-08-06, rev 0x00b7, size 4096

das scheint mir für einen Q6600 'ne passable history zu sein.
Da ist kein Update für 2018 zu sehen.

Kannst ja mal
# dmesg | grep microcode
posten

[nudgegoonies]

Ich habe das neue Paket jetzt mal ausprobiert. Was auch immer sich am File geändert hat, die Microcode Version, die /proc/cpuinfo meldet ist gleich geblieben. Vielleicht nur anders signiert?

P.S.
Hier wird diskutiert, ob die Regression die Probleme verursacht bei Linux gar nicht auftreten kann: https://bugs.debian.org/cgi-bin/bugrepo ... bug=886998

[dufty2]

Ich habe das neue Paket jetzt mal ausprobiert. Was auch immer sich am File geändert hat, die Microcode Version, die /proc/cpuinfo meldet ist gleich geblieben. Vielleicht nur anders signiert?

Wäre ganz nett, wenn Du die Ausgabe von

Code: Alles auswählen

# dmesg | grep microcode

posten würdest, Dann könnte man sehen, ob mein Signaturgerate (sig 0x000006fb) richtig war (oder nicht.) und wann das letzte microcode-update erfolgt ist (2010-10-03).

Hier wird diskutiert, ob die Regression die Probleme verursacht bei Linux gar nicht auftreten kann: https://bugs.debian.org/cgi-bin/bugrepo ... bug=886998

Der neue sid-Kernel (4.14.12-2) verursacht auf jeden Fall Probleme, deswegen ist er auch bis jetzt noch nicht in testing gelandet,
vgl. auch https://tracker.debian.org/pkg/linux

[Ellison]

@Ellison:
Da die 100Hz den 10ms in Kernel 2.4 entsprechen, kannst du dir den Sarge-Test eigentlich sparen. Was der Sempron mit aktuellem Kernel zum Thema Spectre sagt, wäre vielleicht trotzdem interessant.

Hätte ich gerne gestern abend ausgiebig testen wollen, aber der Rechner verweigert seinen Dienst. Stand wohl zu lange auf dem Dachboden herum. Zuckt nicht mal. Das Netzteil funktioniert. Geht dann eben zum E-Schrott.

[dufty2]

So, sid hat jetzt den 4.14.13-1 und damit heisst es nicht mehr "cpu_insecure", sondern

Code: Alles auswählen

$ cat /proc/cpuinfo | grep -m 1 bugs
bugs		: cpu_meltdown

Lt. dem Phoronix-Artikel [1] soll in 4.14.14 dann "Retpoline" (für Spectre Variant 2) landen.
Da sind wir mal gespannt
Vgl. auch https://git.kernel.org/pub/scm/linux/ke ... nux-4.14.y

[1] https://www.phoronix.com/scan.php?page= ... -Retpoline

[ingo2]

Sieht so aus, als wenn Intel auch versucht hätte, die Firmware von Sandy-Bridge un Ivy-Bridge zu patchen. Offenbar gibt es aber dann Probleme mit häufigeren Reboots:
https://www.reuters.com/article/us-cybe ... SKBN1F7087
Da werden wohl wegen Fehlern NMI's vom Watchdog ausgelöst.

Wenn man das mal etwas überdenkt, könnte es doch sein, daß die angeblichen Firmware-Fehler bewußt eingeführt wurden, um die Stabilität der CPU's zu gewährleisten - d.h. indirekt einen Designfehler zu kaschieren. Oder eine höhere Taktfrequenz stabil zu erzielen, oder? Später hat man dann gemerkt, daß das Ganze einen Geschwindigfkeitsvorteil bringt und es dann so belassen hat?

EDIT:
Hier noch ein Link zum Thema:
http://www.zdnet.de/88323551/intel-rebo ... c45b8b479d