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

[hikaru]

Ich habe bei mir ein Notebook mit Ivy-bridge (IntelCore I3-3110M) und eins mit Sandy- bridge (IntelCore I5-2450M).
Soweit ich weiß sind beide (durch die Updates von Stretch und dessen Kernel) gegen Meltdown abgesichert.

Richtig.

Laut diesem Thread habe ich auch verstanden das es mit Absicherung gegen Spectre schwierig wird bzw. gar nichts wird.

Jetzt meine Frage:
Wie kann man sich das "Spectre" einfangen, bzw. verhindern (neuen Firefox (57.0.4.) unter Stretch installieren?). Würde das dann schon ausreichen?

Soweit öffentlich bekannt, gibt es abgesehen von den Demo-Exploits noch nichts das Spectre ausnutzt. Demnach kann das momentan auch nicht ausgenutzt werden.
Was diverse Schlapphüte und andere Ganoven hinter verschlossenen Türen wissen und tun, kann natürlich keiner sagen. Einen endgültigen Schutz vor Spectre wird es ohne neue Hardwaredesigns nicht geben, man kann sich mit ständigen Updates dem nur annähern.

Insofern halte ich auch diese Aussage für optimistisch:

Nicht für jeden ist das irgend etwas besonders beunruhigendes....

https://www.unix.com/what-is-on-your-mi ... -bugs.html

Die Aussage an sich mag stimmen oder auch nicht. Der verlinkte Thread enthält aber nichts Gehaltvolles, das eine Entscheidung in die eine oder andere Richtung beeinflussen könnte.

Meine CPU Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz ist auf der Intel Seite für dieses Nicrocode Update gelistet.

Es sind wohl noch nicht alle Fixes eingepflegt, für die Intel einen Fix angekündigt hat. Mit Haswell als ältester überhaupt berücksichtigten Generation stehst du wahrscheinlich ganz hinten in der Schlange. Wenigstens stehst du drin.

Wo du als Kernel-Experte schon mal da bist:
Von Performanceaspekten abgesehen, wenn ich in der Debian-Kernel-Config CONFIG_HIGH_RES_TIMERS=y und CONFIG_HZ_250=y deaktiviere, sowie CONFIG_HZ=250 auf 50 ändere, kriege ich dann einen Kernel der nur Zeitmessungen auf 20ms genau erlaubt und demnach als globale Spectre-Gegenmaßnahme taugt, falls an Mozillas Timer-Verschlechterung in Firefox auf 20ms was dran ist?
Oder übersehe ich hier weitere Optionen bzw. habe gar einen grundsätzlichen Denkfehler?

[towo]

Von Performanceaspekten abgesehen, wenn ich in der Debian-Kernel-Config CONFIG_HIGH_RES_TIMERS=y und CONFIG_HZ_250=y deaktiviere, sowie CONFIG_HZ=250 auf 50 ändere, kriege ich dann einen Kernel der nur Zeitmessungen auf 20ms genau erlaubt und demnach als globale Spectre-Gegenmaßnahme taugt, falls an Mozillas Timer-Verschlechterung in Firefox auf 20ms was dran ist?

Ich glaube nicht, daß das irgendeine Auswirkung als Gegenmaßnahme hätte. Wäre dem so, wären die Kernel-Devs die Ersten gewesen, die das kommuniziert hätten und es wäre vermutlich sogar als default-config upstream gelandet.

[dufty2]

Meine CPU Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz ist auf der Intel Seite für dieses Nicrocode Update gelistet.

Es sind wohl noch nicht alle Fixes eingepflegt, für die Intel einen Fix angekündigt hat. Mit Haswell als ältester überhaupt berücksichtigten Generation stehst du wahrscheinlich ganz hinten in der Schlange. Wenigstens stehst du drin.

$ grep HSW releasenote
HSW-ULT Cx/Dx (06-45-01:72) 20->21
HSW Cx/Dx (06-3c-03:32) 22->23

Naja, irgendwas haben sie bei Haswell reingepanscht, was genau kann ich aber nicht sagen.

[dufty2]

So, noch ein paar Links zum "rumspielen":

Ein Testskript: https://github.com/speed47/spectre-meltdown-checker

Proof of Concept für meltdown: https://github.com/iaik/meltdown

Angriff im Browser: http://xlab.tencent.com/special/spectre ... check.html

Entnommen aus https://github.com/hannob/meltdownspectre-patches

[ingo2]

Hm, sehr eigenartig

Neue intel-microcode 3.20180108.1 und es ändert sich genau nichts.

Ich an deiner Stelle wäre froh.
Vergiß nicht, daß Intel seit Mitte letzten Jahres über den /di Bugs bescheid weiß - und für den 9.1.18 sollte es öffentlich werden. Da hatten sie ja ½ Jahr Zeit.

[hikaru]

Von Performanceaspekten abgesehen, wenn ich in der Debian-Kernel-Config CONFIG_HIGH_RES_TIMERS=y und CONFIG_HZ_250=y deaktiviere, sowie CONFIG_HZ=250 auf 50 ändere, kriege ich dann einen Kernel der nur Zeitmessungen auf 20ms genau erlaubt und demnach als globale Spectre-Gegenmaßnahme taugt, falls an Mozillas Timer-Verschlechterung in Firefox auf 20ms was dran ist?

Ich glaube nicht, daß das irgendeine Auswirkung als Gegenmaßnahme hätte. Wäre dem so, wären die Kernel-Devs die Ersten gewesen, die das kommuniziert hätten und es wäre vermutlich sogar als default-config upstream gelandet.

CONFIG_HZ_250=y kann man nicht einfach weglassen. Man kann es gegen sowas wie CONFIG_HZ_100=y oder CONFIG_HZ_1000=y ersetzen, aber darunter kommt man nicht. Man kriegt dann bestenfalls einen 100Hz-Kernel.
Damit und mit dem Standardkernel habe ich je 1000x die Spectre-Attack-Demo auf meinem Ivy Bridge laufen lassen und habe die fehlgeschlagenen Charactererkennungen aus dem Opferstring gezählt. Beide haben einen Median von 2, beim Standardkernel mit einer Standardabweichung von 2,37, beim 100Hz-Kernel mit einer von 2,17.
Meine Statistikvorlesungen sind zu lange her um das zu bewerten, aber aus der Hüfte würde ich schießen, dass der Unterschied nicht ausreicht um eine Tendenz abzulesen.

@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.

[ChronoBoost]

Beide haben einen Median von 2, beim Standardkernel mit einer Standardabweichung von 2,37, beim 100Hz-Kernel mit einer von 2,17.
Meine Statistikvorlesungen sind zu lange her um das zu bewerten, aber aus der Hüfte würde ich schießen, dass der Unterschied nicht ausreicht um eine Tendenz abzulesen.

Richtig geschossen.

Das Verhältnis der Standardabweichungen ist F-verteilt:
F=2.37/2.17=1.0921 < Fcrit(999,999,5%)=1.1097

[NAB]

Liebe Leute ... ich wollte hier auch noch kurz ein paar Infos loswerden:
1) Welche Prozessoren kriegen Microcode-Updates?
Die Thomas Krenn AG erwartet BIOS-Updates für ihre Supermicro-Boards bis runter zu Nehalem:
https://www.thomas-krenn.com/de/wiki/Si ... nd_Spectre
und beruft sich dabei auf Supermicro:
https://www.supermicro.com/support/secu ... pg=X10#tab
Nun sind das nur Ankündigungen ... und nur Server-Prozessoren ... aber warten wir mal ab.

2) Spectre-Tests
Der Link von duffy2
Angriff im Browser:
http://xlab.tencent.com/special/spectre ... check.html
sagt für meinen alten Firefox ESR 52, er sei nicht angreifbar - sollte er aber momentan sein, sagt die (Fach)Presse.
Warum geht's trotzdem nicht?
Die Seite nutzt "SharedArrayBuffer" für den Angriff, und das ist im ESR 52 eh abgeschaltet:
https://www.mozilla.org/en-US/security/ ... sa2018-01/
(Das verschweigt die Fachpresse)
Wirklich "gefixed" wurde bei mir noch nichts, keine neuen Microcodes, keine recompiled binaries und der Firefox ESR ist vom 8. Dezember. Also vorsicht bei solchen angeblichen Browser-Tests.
(Der "spectre-meltdown-checker" ebenfalls von duffy2 sieht da wesentlich solider aus)

Oh ... hier eine kurze Anleitung, wie man diesen spectre-meltdown-checker anschmeißt:
https://www.cyberciti.biz/faq/check-lin ... erability/
Leider auf Englisch, aber die beiden wichtigen Zeilen sind die, die mit "wget" und mit "sudo" anfangen.

[hikaru]

Liebe Leute ... ich wollte hier auch noch kurz ein paar Infos loswerden:
1) Welche Prozessoren kriegen Microcode-Updates?
Die Thomas Krenn AG erwartet BIOS-Updates für ihre Supermicro-Boards bis runter zu Nehalem:
https://www.thomas-krenn.com/de/wiki/Si ... nd_Spectre
und beruft sich dabei auf Supermicro:
https://www.supermicro.com/support/secu ... pg=X10#tab
Nun sind das nur Ankündigungen ... und nur Server-Prozessoren ... aber warten wir mal ab.

Zwei Anmerkungen zu dem Wiki-Artikel (bzw. deiner Interpretation):

1. Ich finde, dort wird die meiste Zeit nicht sauber genug zwischen Meltdown und Spectre unterschieden. In Anbetracht der Reputation von Thomas-Krenn finde ich das schwach.

2. Für Nehalem bis Ivy Bridge steht dort "Entwicklung in Vorbereitung" und der Satz:

BIOS Updates für Systeme der [Generation] Generation werden entwickelt, sobald Microcode Updates dafür zur Verfügung stehen:

Ich verstehe das so, dass Supermicro bereit wäre, Updates mit neuen Microcodes zu liefern, falls (nicht wenn) diese von Intel geliefert werden.
Dafür DASS Intel Updates liefert sehe ich dort aber keinen Hinweis. Der jeweils dazugehörige englische Satz geht so los:

We are awaiting microcode updates [..]

Das "awaiting" kann man mit "erwarten" übersetzen, hier passt mMn aber besser "abwarten". Ersteres impliziert die Annahme, dass etwas passiert, Letzteres nicht.

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.

[MSfree]

Seit meinem gestrigen apt-get dist-upgrade meines Jessie Heimservers liefern:

Code: Alles auswählen

uname -a
Linux cargobay 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux

Code: Alles auswählen

dmesg | grep -i iso
[    0.000000] Kernel/User page tables isolation: enabled

Gegen Meltdown wurde der Kernel also schon abgedichtet.

Code: Alles auswählen

dmesg | grep -i micro
[    0.000000] CPU0 microcode updated early to revision 0x1c, date = 2015-02-26
[    0.080021] CPU1 microcode updated early to revision 0x1c, date = 2015-02-26
[    0.093493] CPU2 microcode updated early to revision 0x1c, date = 2015-02-26
[    0.106995] CPU3 microcode updated early to revision 0x1c, date = 2015-02-26

Gegen Spectre habe ich also noch keine Updates.

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.

[TuxPeter]

Angriff im Browser:
http://xlab.tencent.com/special/spectre ... check.html
sagt für meinen alten Firefox ESR 52, er sei nicht angreifbar

Für meinen auch. 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?

Zwar verstehe ich diese Diskussion hier nur zu kleinen Teilen, frage mich aber doch, was ich als diesbezüglich recht unbedarfter User eigentlich sinnvolles tun kann:

• - fleißig nach Debian-Updates schauen + einspielen, (was mir ja sonst bei Stable nicht sonderlich dringend erscheint)
  - ebenso fleißig nach Bios-Updates schauen + einspielen, wenn vorhanden.
  - Wichtige Passw. nicht per Browser speichern (die drei, vier wirklich wichtigen PWs hatte ich da sowieso nie)
  - 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?)

Noch interessanter wäre die Frage, ob diese drei, vier wichtigen Passwörter jetzt geändert werden sollten - wo doch vermutlich gerade währende einer Änderung mehrmals neu und umcodiert wird, was die PWs nach meinem Verständnis viel leichter angreifbar macht, als wenn sie still und hoffentlich gut verschlüsselt irgendwo vor sich hin rotieren.

Edit: Hatte Msfree's Beitrag noch nicht auf dem Schirm. Dmesg nach dem Stand zu fragen, war mir nicht eingefallen.
bei mir kommt:

~# dmesg | grep -i micro
[ 0.505811] microcode: sig=0x906e9, pf=0x2, revision=0x70
[ 0.505858] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

scheint damit schon drin zu sein.

[novalix]

- fleißig nach Debian-Updates schauen + einspielen, (was mir ja sonst bei Stable nicht sonderlich dringend erscheint)

Da möchte ich noch mal kurz einhaken.
Da draußen in der Wildnis existieren Sicherheitslücken, die man aus einer bestimmten Perspektive in zwei Kategorien einteilen kann.
1. Lücken, die akademisch als Proof-of-Concept nachgewiesen werden
2. Lücken, die auffallen, weil sie aktiv von Böslingen ausgenutzt werden

Beide Sorten werden fortlaufend - so gut es eben gelingt - mit Patches geschlossen. Bei zweiteren ist es offensichtlich wichtig, dass sie so zeitnah, wie es eben geht, eingespielt werden. Das gilt auch für stable.

"Sicherheit" ist ein gutes Beispiel dafür, wie unsere interpretative Ökonomie funktioniert und wieso unser Weltbild notwendigerweise genau da lückenhaft ist, wo es uns am geschlossensten erscheint.
Die meisten tödlichen Unfälle passieren im Haushalt und die wandernde Kröte ist auch dann platt, wenn der SUV sie mit 30 anstatt mit 50 km/h überrollt.
Das soll jetzt bitte schön kein Vorwurf sein und auch kein Plädoyer für kontinuierliche Paranoia, aber in diesem Boot sitzen wir nun mal alle zusammen.

tl;dr: An Update a day, keeps the doctor away (hopefully)

[rendegast]

STRATO nimmt diese Schwachstellen ernst. Als wir davon erfahren
haben, haben wir umgehend reagiert. Um die Schwachstellen zu
beheben, sind Aktualisierungen in Form von Patches und Updates an
den entsprechenden Systemen notwendig. Bei STRATO arbeiten derzeit
zahlreiche Technik-Teams, die unsere Plattformen betreuen, mit
höchster Priorität daran, die Plattformen mit diesen
Aktualisierungen zu versorgen.

Wir aktualisieren momentan sämtliche Systeme für unsere Produkte
direkt, sobald wir die entsprechenden Aktualisierungen erhalten.
Dabei sind wir auf die Zuarbeit der Hersteller angewiesen, die uns
diese Aktualisierungen bereitstellen. Deshalb stehen wir aktuell im
ständigen Austausch mit den Herstellern und unseren verschiedenen
Partnern.

"zahlreiche Technik-Teams" sitzen also rum und trinken Kaffee, bis im 'apt-get (dist-)upgrade' linux-image und/oder intel-microcode auftauchen?

Wir möchten Ihnen versichern: Bislang haben wir keine Anhaltspunkte
dafür, dass Unbefugte bei STRATO eine der Schwachstellen ausgenutzt
hätten.

Wohl einfach nur falsch, denn der Anhaltspunkt ist ja, daß die Lücke(n) seit Jahren existiert.

[Animefreak79]

Original von MsFree
Gegen Meltdown wurde der Kernel also schon abgedichtet.

Gegen Meltdown wurde der Kernel unter meinem Stretch schon vor ein paar Tagen abgedichtet. Momeeeent... *Mal kurz nachschau*
https://www.debian.org/security/
Also am 04. Januar. Jessie bekam den fix am 09. Januar... Gegen Spectre wird es laut dem Debianteam wohl später ein Update geben. Aber ich mache mir da auch nicht allzu viele Sorgen. Klar, wenn ich ein gewisses OS der Firma Microsoft nutzen würde, dann wäre das wohl anders... Aber so... 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. Unwahrscheinlich... Aber (natürlich) nicht unmöglich. Und da es sich ja um einen Designfehler in der Hardware handelt... Wie lange wird es denn letztendlich dauern, bis die Fehler ausgemerzt sind? Möglicherweise noch ein paar Jahre, oder?

Original von novalix
Die meisten tödlichen Unfälle passieren im Haushalt und die wandernde Kröte ist auch dann platt, wenn der SUV sie mit 30 anstatt mit 50 km/h überrollt.
Das soll jetzt bitte schön kein Vorwurf sein und auch kein Plädoyer für kontinuierliche Paranoia, aber in diesem Boot sitzen wir nun mal alle zusammen.

Hundertprozentige Sicherheit wird es eben nie geben, dessen sollten wir uns immer bewusst sein!

[schwedenmann]

Hallo


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

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

mfg
schwedenmann

[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.