debianforum.de

Verfasst: **10.01.2018 15:36:30**

@inne:
Beide CPUs sind von Meltdown (ohne KPTI) und Spectre betroffen. Der erste ist ein Ivy Bridge, für den es nach aktuellem Stand keine neuen Microcodes gegen Spectre geben wird. Der zweite ist ein Haswell, für den es neue Microcodes gibt, die zumindest zum Teil Abhilfe schaffen sollen (

intel-microcode ab Version 3.20171215.1).

inne hat geschrieben:
10.01.2018 14:57:02
// Ganz allgemein wäre am Ende, wenn das Thema durch ist ein Zusammenfassung für den Enduser interessant. Welche Hardware wurde gefixed, welche nicht und was kauft man in der Zukunft für Hardware.

Möchtest du dafür ab 2021 einen Termin vormerken, oder machen wir das dann spontan?

Früher wird es wohl entwicklungsbedingt keine Hardware-Fixes geben. Ich las dazu etwas auf Twitter von einem ehemaligen Intel-Entwickler, der erklärte, wie etwa der Entwicklungszyklus läuft und warum das so lange dauert. Leider habe ich die Quelle nicht im Kopf.

Verfasst: **10.01.2018 15:40:18**

ingo2 hat geschrieben:
10.01.2018 15:33:47
Check doch einfach mit dem neuesten "intel-microcode" und schau mit "dmesg" nach, welches Datum die Updates haben - sollt nach Juni 2016 liegen

Du meinst Juni 2017 (da wurden die Hersteller informiert).
Was die neuen Microcodes machen wissen wir leider trotzdem nicht. Wenn ich böse wäre würde ich jetzt behaupten, Intel hat einfach nur den Datumsstring aktualisiert.

Verfasst: **10.01.2018 16:14:17**

Hallo Leute,

Irgendwie blicke ich nicht so richtig durch.

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.

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?

Edit. Gerade gelesen:"Praktisch muss man es bei den Angriffen, die wir präsentiert haben, nur schaffen, dass die dafür nötige Software auf dem angegriffenen System läuft", sagt Daniel Gruss. Auf dem Rechner könne sie zum Beispiel in Form eines E-Mail-Anhangs oder eines Downloads landen."

(http://www.spiegel.de/netzwelt/gadgets/ ... 86193.html)

Danke

Verfasst: **10.01.2018 16:29:22**

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

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

Verfasst: **10.01.2018 16:45:56**

Hm, sehr eigenartig

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

boot mit microcode 3.20171215.1

Code: Alles auswählen

Jan 10 16:18:02 Defiant kernel: microcode: microcode updated early to revision 0x23, date = 2017-11-20
Jan 10 16:18:02 Defiant kernel: microcode: sig=0x306c3, pf=0x2, revision=0x23
Jan 10 16:18:02 Defiant kernel: microcode: Microcode Update Driver: v2.2.

nach update auf 3.20180108.1

Code: Alles auswählen

Jan 10 16:27:52 Defiant kernel: microcode: microcode updated early to revision 0x23, date = 2017-11-20
Jan 10 16:27:52 Defiant kernel: microcode: sig=0x306c3, pf=0x2, revision=0x23
Jan 10 16:27:52 Defiant kernel: microcode: Microcode Update Driver: v2.2.

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

Verfasst: **10.01.2018 17:12:48**

Aiki09 hat geschrieben:
10.01.2018 16:14:17
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.

Aiki09 hat geschrieben:
10.01.2018 16:14:17
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:

heisenberg hat geschrieben:
10.01.2018 16:29:22
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.

towo hat geschrieben:
10.01.2018 16:45:56
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?

Verfasst: **10.01.2018 17:24:20**

hikaru hat geschrieben: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.

Verfasst: **10.01.2018 17:35:19**

hikaru hat geschrieben:
10.01.2018 17:12:48

towo hat geschrieben:
10.01.2018 16:45:56
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.

Verfasst: **10.01.2018 21:34:11**

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

Verfasst: **10.01.2018 21:34:47**

towo hat geschrieben:
10.01.2018 16:45:56
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.

Verfasst: **10.01.2018 23:05:54**

towo hat geschrieben:
10.01.2018 17:24:20

hikaru hat geschrieben: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.

Verfasst: **11.01.2018 00:09:39**

hikaru hat geschrieben:
10.01.2018 23:05:54
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

Verfasst: **11.01.2018 04:56:15**

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.

Verfasst: **11.01.2018 09:04:56**

NAB hat geschrieben:
11.01.2018 04:56:15
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.

Verfasst: **11.01.2018 09:33:54**

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.

Verfasst: **11.01.2018 10:03:44**

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.

Verfasst: **11.01.2018 12:12:05**

TuxPeter hat geschrieben:
11.01.2018 10:03:44
- 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)

Verfasst: **11.01.2018 12:12:20**

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.

Verfasst: **11.01.2018 12:32:56**

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!

Verfasst: **11.01.2018 12:56:15**

Hallo

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

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

mfg
schwedenmann

Verfasst: **11.01.2018 13:18:30**

Animefreak79 hat geschrieben: Hundertprozentige Sicherheit

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

Verfasst: **11.01.2018 13:26:52**

Animefreak79 hat geschrieben:
11.01.2018 12:32:56
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.

Animefreak79 hat geschrieben:
11.01.2018 12:32:56
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.

schwedenmann hat geschrieben:
11.01.2018 12:56:15
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.

rendegast hat geschrieben:
11.01.2018 12:12:20
STRATO

rendegast hat geschrieben:
11.01.2018 13:18:30
blafasel.

Gute Zusammenfassung.

Verfasst: **11.01.2018 13:49:14**

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

Verfasst: **11.01.2018 13:50:25**

MSfree hat geschrieben:
11.01.2018 09:33:54
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?

Verfasst: **11.01.2018 14:50:12**

Ist doch Juli 2017.

debianforum.de

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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