ist wie "gültige Erlaubnis".Animefreak79 hat geschrieben: Hundertprozentige Sicherheit
Beide Adjektive sind blafasel.
ist wie "gültige Erlaubnis".Animefreak79 hat geschrieben: Hundertprozentige Sicherheit
Im Prinzip kann jede Webseite die du im Browser aufrufst einen Spectre-Angriff fahren.Animefreak79 hat geschrieben:11.01.2018 12:32:56Man 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.
Auf derzeitig betroffener Hardware wird Spectre nie wirklich ausgemerzt sein, egal was da noch für Updates kommen mögen.Animefreak79 hat geschrieben:11.01.2018 12:32:56Wie lange wird es denn letztendlich dauern, bis die Fehler ausgemerzt sind? Möglicherweise noch ein paar Jahre, oder?
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.schwedenmann hat geschrieben:11.01.2018 12:56:15Benchmarks von Intel, max. -10% , SSDS noch mehr betroffen
https://www.heise.de/newsticker/meldung ... 38747.html
Gute Zusammenfassung.
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 die wandernde Kröte ist auch dann platt, wenn der SUV sie mit 30 anstatt mit 50 km/h überrollt.
Für Haswell neuer Mikrocode? intel-microcode und iucode-tool sind installiert.MSfree hat geschrieben:11.01.2018 09:33:54Meine 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.
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
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
...
ja sind sie..Colttt hat geschrieben:08.01.2018 21:36:08Nur so aus neugier, sind den (Open)Power und Sparc-Prozessoren auch betroffen?
Wenn nicht, ob's da jetzt nen Run drauf gibt?
Diese Intel-Seite verwirrt doch ziemlich viele Leute.Jana66 hat geschrieben:11.01.2018 13:50:25
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?
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
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.dufty2 hat geschrieben:11.01.2018 15:10:28In 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).
Um Nochmal der Verwirrung Klarheit zu verschaffen:Jana66 hat geschrieben:11.01.2018 15:54:38Passt dann aber nicht unbedingt zu einem Backport-Kernel.
Ist eventuell sogar eine Masche des Marketings:MSfree hat geschrieben:11.01.2018 09:33:54... Intel liefert im Moment nur Micorcodes für CPUs, die maximal 5 Jahre alt sind, also Hasswell und neuer.
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.hikaru hat geschrieben:11.01.2018 09:04:56Letztendlich 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.
Siehst du ... da haben wir schon den ersten Unterschied. Als ich da drauf geklickt habe, passierte erst mal gar nichts. Warum?TuxPeter hat geschrieben:11.01.2018 10:03:44Aber 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?
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.TuxPeter hat geschrieben:11.01.2018 10:03:44Wichtige Passw. nicht per Browser speichern (die drei, vier wirklich wichtigen PWs hatte ich da sowieso nie)
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?TuxPeter hat geschrieben:11.01.2018 10:03:44- 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?)
Mit einmal wird die Welt ganz klein... *over-n-out*
Und diese Verträge sind so langanhaltend, dass Supermicro mit einem Prozess durchkäme, bevor ihre Verträge mit Intel über Nehalem auslaufen?NAB hat geschrieben:11.01.2018 19:55:06Auf 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.
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).NAB hat geschrieben:11.01.2018 19:55:06Und 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
Yep, einfach mal das script-chen laufen lassen und schon ist mensch schlauer:hikaru hat geschrieben:12.01.2018 09:18:28Die 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).
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
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 ...hikaru hat geschrieben:12.01.2018 09:18:28Und 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? 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.hikaru hat geschrieben:12.01.2018 09:18:28Die 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.
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
Code: Alles auswählen
/lib/firmware/intel-ucode/06-0f-0b
Code: Alles auswählen
md5sum 06-0f-0b
e19ab5b0f342fa6d14d3a48866eac6ed 06-0f-0b
Code: Alles auswählen
md5sum 06-0f-0b
c2c4623aee49a3c35c39f66d01152098 06-0f-0b
Ach du Scheiße ...nudgegoonies hat geschrieben:12.01.2018 21:01:47https://www.heise.de/newsticker/meldung ... 40326.html
Mmmh, also im source-file von Intel hat das ne andere md5sum:nudgegoonies hat geschrieben:12.01.2018 21:01:47Ich 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
Code: Alles auswählen
$ md5sum intel-ucode/06-0f-0b
4518fa18328a5c79ba6263ecd741b2c1 intel-ucode/06-0f-0b
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
Wäre ganz nett, wenn Du die Ausgabe vonnudgegoonies hat geschrieben:14.01.2018 12:44:07Ich 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?
Code: Alles auswählen
# dmesg | grep microcode
Der neue sid-Kernel (4.14.12-2) verursacht auf jeden Fall Probleme, deswegen ist er auch bis jetzt noch nicht in testing gelandet,nudgegoonies hat geschrieben:14.01.2018 12:44:07Hier wird diskutiert, ob die Regression die Probleme verursacht bei Linux gar nicht auftreten kann: https://bugs.debian.org/cgi-bin/bugrepo ... bug=886998
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.hikaru hat geschrieben:10.01.2018 23:05:54@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.
Code: Alles auswählen
$ cat /proc/cpuinfo | grep -m 1 bugs
bugs : cpu_meltdown