Eine Sache ist mir dabei aber aufgefallen Keine Ahnung, ob ich da unzureichend informiert bin oder der Artikel halt auch mal wieder ungenau.
Es steht da, dass sowohl Meltdown als auch Spectre beliebigen Speicher auslesen können. nach meinem Kenntnisstand sieht es so aus, dass man mit Meltdown auf den gesamten Speicher der zugrunde liegenden Hardware zugreifen kann, also von einer VM aus den Speicher einer anderen auslesen.
Bei Spectre ist es nur möglich, auf den Speicher der laufenden Anwendung zuzugreifen. Also eine Webseite installiert ein Script, mit dem ich dann die von diesem Browser gespeicherten und aktuell genutzten Passwörter zugreifen kann. Mehr nicht.
Des weiteren sollte gesagt werden, dass Meltdown einfach so funktioniert. Für Spectre ist da das Timing entscheidend. Auch darauf geht der Artikel nicht ein. Wie im Artikel beschrieben, kann man durch Laufzeitunterschiede feststellen, wo die Daten liegen. Dafür muss der Exploit aber an jede CPU angepasst werden und z.B. hat Mozilla ja gerade die Genauigkeit dieses Timers so heruntergesetzt, dass es sehr schwierig wird, diesen Bug auszunutzen.
Und nach weiteren Informationen wird sich Spectre nicht softwaremäßig patchen lassen. Da hilft kein neuer Kernel. Da hilft nur ein komplett neues CPU-Design. Welches wir von Intel freiwillig nie bekommen werden.
Präziser gesagt, kann Meltdown auf den Speicher des Kernels zugreifen. Das interpretiere ich wie du so, dass es auf den gesamten Speicher zugreifen kann, da der Kernel diesen ja gemappt hat. Hätte ich vielleicht klarer ausdrücken können.
Die Spectre-Geschichte interpretierte ich etwas anders, aber nun gut, das ist ziemlich komplex. Es sieht in der Tat so aus, als wäre keine vollständige Lösung in Software möglich. Zumindest sind aber Patches gegen Spectre im Entstehen. Das hat Greg K-H geschrieben und bei LWN und natürlich auf der Kernel-Mailingliste gibt es Details. Gegen Variante 1 sollen das Makro nospec_array_ptr, neue Direktiven in GCC und Einschränkungen bei eBPF helfen. Gegen Variante 2 werden IBRS (was ein Microcode-Update erfordert) und »retpolines« getestet.
Eine Sache ist mir dabei aber aufgefallen Keine Ahnung, ob ich da unzureichend informiert bin oder der Artikel halt auch mal wieder ungenau.
Es steht da, dass sowohl Meltdown als auch Spectre beliebigen Speicher auslesen können. nach meinem Kenntnisstand sieht es so aus, dass man mit Meltdown auf den gesamten Speicher der zugrunde liegenden Hardware zugreifen kann, also von einer VM aus den Speicher einer anderen auslesen.
Bei Spectre ist es nur möglich, auf den Speicher der laufenden Anwendung zuzugreifen. Also eine Webseite installiert ein Script, mit dem ich dann die von diesem Browser gespeicherten und aktuell genutzten Passwörter zugreifen kann. Mehr nicht.
Des weiteren sollte gesagt werden, dass Meltdown einfach so funktioniert. Für Spectre ist da das Timing entscheidend. Auch darauf geht der Artikel nicht ein. Wie im Artikel beschrieben, kann man durch Laufzeitunterschiede feststellen, wo die Daten liegen. Dafür muss der Exploit aber an jede CPU angepasst werden und z.B. hat Mozilla ja gerade die Genauigkeit dieses Timers so heruntergesetzt, dass es sehr schwierig wird, diesen Bug auszunutzen.
Und nach weiteren Informationen wird sich Spectre nicht softwaremäßig patchen lassen. Da hilft kein neuer Kernel. Da hilft nur ein komplett neues CPU-Design. Welches wir von Intel freiwillig nie bekommen werden.
Ich beobachte unter Fedora 26 (Kernel: 4.14.11) in den vergangenen Tagen bis Wochen verstärkt Instabilitäten (Fehler beim Drag & Drop von Dateien bis hin zu Kernel-Abstürzen).
Habt ihr das auch? Wie sieht es bei anderen Distris aus? Könnt ihr eine zunehmende Fehlerhäufigkeit bestätigen, oder ist bei euch noch alles OK?
Neuer Kernel lässt sich installieren aber er funktioniert überhaupt nicht richtig. Kernel Startet 4 Pinguine am Himmel und dann reboot in einer Endlosschleife und das reproduzierbar. Abartig, sowas kenne ich gar nicht.
Ich meine, von solchen Problemen irgendwo gelesen zu haben. Ist es ein offizieller CentOS-Kernel? Das sollte denen nicht passieren. Vermutlich findest du auf den CentOS-Mailinglisten Abhilfe.
Ja ist der offizielle CentOS-Kernel kernel-3.10.0-693.11.6.el7. Bin ja auch erstaunt kenne so etwas von denen nicht. Alle anderen Kernel funktionieren wie gehabt ohne Probleme.
Von Bolle vom Berg am Mo, 8. Januar 2018 um 21:01 #
wollte nur mal anmerken, dass ich bisher ziemlich viele Artikel zu Spectre und Meltdown gelesen habe, aber H.J. Baader mir es von allen am verständlichsten rüberbringen konnte.
Von Thomas Schütz am Di, 9. Januar 2018 um 08:48 #
Dem kann ich mich nur anschließend, ich habe die Nachrichten dazu auf vielen News-Seiten gelesen, aber oftmals war das eher verwirrend als informativ, gerade die IT-Seiten sind dabei zu abgehoben technisch gewesen. Nach dem Pro-Linux-Artikel weiß man, worum es geht, "1 mit Sternchen, setzen, danke!"
Ich werde mit Sicherheit auch so manche Nicht-Linuxer mal auf den Artikel hinweisen.
Herzlichen Dank. Hier glaube ich an Wahrheit im Artikel. Hier habe ich Vertrauen! Macht weiter so ! Auch wenn es hier um Linux geht wäre es nett wenn man auch einen Blick auf Android werfen würde, schliesslich ist es auch weit verbreitet.
Danke! Was Android angeht, habe ich schon in der News vom 4. Januar erwähnt, dass Google die noch unterstützten Android-Versionen bereits gepatcht hat. Heute habe ich aus Zeitmangel nichts mehr dazu geschrieben. Auch Hinweise auf weitere Artikel musste ich mir wegen der begrenzten Zeit sparen.
Tja, meine Lieblings-Distro ist in der 32bit-Variante istalliert und daher auch betroffen, und meine Zweit-Distri (Lubuntu64) hat noch keinen gefixten Kernel ausgerollt.
Also wird erst mal mit abgeschaltetem Javascript gesurft, und nach dem Lubuntu-Update werde ich wohl erst mal auf Lubuntu64 ausweichen müssen.
Wenn keine gepatchten 32bit-Kernel vorliegen sollten, dann liegt das eher an der Distribution.
Es sei denn, die neuen 32bit-2.6.32-Kernel für CentOS6 (und damit für RHEL6) wären im Bezug auf Meltdown reiner Fake, was ich nicht annehme: https://lists.centos.org/pipermail/centos-announce/ 2018-January/022701.html
Zudem ist aktuell zuwenig über die konkrete Art und Weise der Betroffenheit von alten 32bit-Systemen im Hinblick auf Meltdown und Spectre bekannt. Das Gemixe zwischen Kernel- und Userland-Speicheradressen unterliegt dort zum einen meist den Regularien des 1GB-/3GB-RAM-Splits (das erst 1GB für den Kernel (low-memory area), die folgenden 3GB für Userland-Speicheradressen) und zum anderen könnte man u.U. mit einem Abschalten des CPU-L1-Caches zumindest Meltdown entgegenwirken.
Ob das aber wirklich so zutrifft, weiß ich allerdings momentan nicht.
Die momentane Funkstille bei Intel im Hinblick auf die Betroffenheit der 32bit-Intelsysteme etwa mit Meltdown ist IMO unerhört. Intel glaubt tatsächlich, dass Sie mit der Strategie durchkommen werden, nur die CPUs mit Software-Updates (u.a. Microcode-Updates) zu versorgen, die seit 2013 gebaut wurden. Alle älteren CPUs wären somit quasi von Intel "aufgegeben".
Es sei denn, die neuen 32bit-2.6.32-Kernel für CentOS6 (und damit für RHEL6) wären im Bezug auf Meltdown reiner Fake, was ich nicht annehme
Beim Ubuntu-Kernelupdate für Kernel 4.13 ist das aber exakt so. Nach dem Update sagt der weiter oben verlinkte Exploit-Test immer noch: "Vulnerable!"
Und auch bei Kernel 4.14.12 direkt von Kernel.org hängt der Parameter für das Schließen der Lücke vom 64bit-Modus ab. Stellt man auf 32 bit um, ist der Parameter aus der Kernel-Menü-Konfiguration ausgeblendet.
Interessant ist dabei, dass aufgrund der unter 32bit noch vorhandenen Segmente Segmentierung selbst ausreicht, weshalb PTI wie unter 64bit gar nicht notwendig ist (64bit macht keinen Gebrauch mehr von dieser Segmentierung). Man kann dabei die Segmentsgrenzen so setzen, dass kein Zugriff auf Kernel-Speicheradressen möglich ist. 32bit wäre dann per Segmentierung gegen Meltdown geschützt, der Performance Hit für 32bit wäre dann bei 0%.
Es muss also niemand seine PIII-, Pentium M- oder PIV-CPU gegen einen PentiumI- oder 32bit-AMD-Prozessor austauschen, um vor Meltdown unter 32bit geschützt zu sein.
Gegenwärtig wird abgecheckt, ob es 32bit-Hardware auf irgendeiner Architektur gibt, die hier Probleme macht und die dann vielelicht doch PTI braucht.
Eine Sache ist mir dabei aber aufgefallen Keine Ahnung, ob ich da unzureichend informiert bin oder der Artikel halt auch mal wieder ungenau.
Es steht da, dass sowohl Meltdown als auch Spectre beliebigen Speicher auslesen können. nach meinem Kenntnisstand sieht es so aus, dass man mit Meltdown auf den gesamten Speicher der zugrunde liegenden Hardware zugreifen kann, also von einer VM aus den Speicher einer anderen auslesen.
Bei Spectre ist es nur möglich, auf den Speicher der laufenden Anwendung zuzugreifen. Also eine Webseite installiert ein Script, mit dem ich dann die von diesem Browser gespeicherten und aktuell genutzten Passwörter zugreifen kann. Mehr nicht.
Des weiteren sollte gesagt werden, dass Meltdown einfach so funktioniert. Für Spectre ist da das Timing entscheidend. Auch darauf geht der Artikel nicht ein. Wie im Artikel beschrieben, kann man durch Laufzeitunterschiede feststellen, wo die Daten liegen. Dafür muss der Exploit aber an jede CPU angepasst werden und z.B. hat Mozilla ja gerade die Genauigkeit dieses Timers so heruntergesetzt, dass es sehr schwierig wird, diesen Bug auszunutzen.
Und nach weiteren Informationen wird sich Spectre nicht softwaremäßig patchen lassen. Da hilft kein neuer Kernel. Da hilft nur ein komplett neues CPU-Design. Welches wir von Intel freiwillig nie bekommen werden.
Präziser gesagt, kann Meltdown auf den Speicher des Kernels zugreifen. Das interpretiere ich wie du so, dass es auf den gesamten Speicher zugreifen kann, da der Kernel diesen ja gemappt hat. Hätte ich vielleicht klarer ausdrücken können.
Die Spectre-Geschichte interpretierte ich etwas anders, aber nun gut, das ist ziemlich komplex. Es sieht in der Tat so aus, als wäre keine vollständige Lösung in Software möglich. Zumindest sind aber Patches gegen Spectre im Entstehen. Das hat Greg K-H geschrieben und bei LWN und natürlich auf der Kernel-Mailingliste gibt es Details. Gegen Variante 1 sollen das Makro nospec_array_ptr, neue Direktiven in GCC und Einschränkungen bei eBPF helfen. Gegen Variante 2 werden IBRS (was ein Microcode-Update erfordert) und »retpolines« getestet.
Eine Sache ist mir dabei aber aufgefallen Keine Ahnung, ob ich da unzureichend informiert bin oder der Artikel halt auch mal wieder ungenau.
Es steht da, dass sowohl Meltdown als auch Spectre beliebigen Speicher auslesen können. nach meinem Kenntnisstand sieht es so aus, dass man mit Meltdown auf den gesamten Speicher der zugrunde liegenden Hardware zugreifen kann, also von einer VM aus den Speicher einer anderen auslesen.
Bei Spectre ist es nur möglich, auf den Speicher der laufenden Anwendung zuzugreifen. Also eine Webseite installiert ein Script, mit dem ich dann die von diesem Browser gespeicherten und aktuell genutzten Passwörter zugreifen kann. Mehr nicht.
Des weiteren sollte gesagt werden, dass Meltdown einfach so funktioniert. Für Spectre ist da das Timing entscheidend. Auch darauf geht der Artikel nicht ein. Wie im Artikel beschrieben, kann man durch Laufzeitunterschiede feststellen, wo die Daten liegen. Dafür muss der Exploit aber an jede CPU angepasst werden und z.B. hat Mozilla ja gerade die Genauigkeit dieses Timers so heruntergesetzt, dass es sehr schwierig wird, diesen Bug auszunutzen.
Und nach weiteren Informationen wird sich Spectre nicht softwaremäßig patchen lassen. Da hilft kein neuer Kernel. Da hilft nur ein komplett neues CPU-Design. Welches wir von Intel freiwillig nie bekommen werden.
Ich beobachte unter Fedora 26 (Kernel: 4.14.11) in den vergangenen Tagen bis Wochen verstärkt Instabilitäten (Fehler beim Drag & Drop von Dateien bis hin zu Kernel-Abstürzen).
Habt ihr das auch? Wie sieht es bei anderen Distris aus? Könnt ihr eine zunehmende Fehlerhäufigkeit bestätigen, oder ist bei euch noch alles OK?
Nope, kein Problem mit Fedora 27 (kernel 4.14.11-300).
Danke, ich sollte mal upgraden.
Neuer Kernel lässt sich installieren aber er funktioniert überhaupt nicht richtig. Kernel Startet 4 Pinguine am Himmel und dann reboot in einer Endlosschleife und das reproduzierbar. Abartig, sowas kenne ich gar nicht.
Ich meine, von solchen Problemen irgendwo gelesen zu haben. Ist es ein offizieller CentOS-Kernel? Das sollte denen nicht passieren. Vermutlich findest du auf den CentOS-Mailinglisten Abhilfe.
Ja ist der offizielle CentOS-Kernel kernel-3.10.0-693.11.6.el7. Bin ja auch erstaunt kenne so etwas von denen nicht. Alle anderen Kernel funktionieren wie gehabt ohne Probleme.
Ach ja und durch setzen von nopti in grub läuft auch dieser Kernel dann korrekt.
Da kann er nix mehr kaputtmachen.
So ein fehlerhaftes Teil kann man patchen bis geht nicht mehr und dann fällt man
dem Spectre-Bug zum Opfer.
Wo liegt das Problem?
Man kann doch als Cloud-Anbieter nicht die Daten zahlender Kunden
kompromittieren lassen.
Also raus mit dem Intel-Zeugs.
Das sind nunmal die Fakten!
Mit den Bugs kann es einem dann egal sein.
Gut das AMD Prozessoren für ein richtiges Backbone liefern kann.
wollte nur mal anmerken, dass ich bisher ziemlich viele Artikel zu Spectre und Meltdown gelesen habe, aber H.J. Baader mir es von allen am verständlichsten rüberbringen konnte.
Dem kann ich mich nur anschließend, ich habe die Nachrichten dazu auf vielen News-Seiten gelesen, aber oftmals war das eher verwirrend als informativ, gerade die IT-Seiten sind dabei zu abgehoben technisch gewesen. Nach dem Pro-Linux-Artikel weiß man, worum es geht, "1 mit Sternchen, setzen, danke!"
Ich werde mit Sicherheit auch so manche Nicht-Linuxer mal auf den Artikel hinweisen.
Herzlichen Dank. Hier glaube ich an Wahrheit im Artikel. Hier habe ich Vertrauen!
Macht weiter so !
Auch wenn es hier um Linux geht wäre es nett wenn man auch einen Blick auf Android werfen würde, schliesslich ist es auch weit verbreitet.
Danke! Was Android angeht, habe ich schon in der News vom 4. Januar erwähnt, dass Google die noch unterstützten Android-Versionen bereits gepatcht hat. Heute habe ich aus Zeitmangel nichts mehr dazu geschrieben. Auch Hinweise auf weitere Artikel musste ich mir wegen der begrenzten Zeit sparen.
Wer wissen will, ob sein System von den Lücken (noch) betroffen ist:
https://github.com/crozone/SpectrePoC
https://github.com/paboldin/meltdown-exploit
Leider ist der Meltdown Fix im Kernel nur für x86-64 verfügbar. Laut grsecurity sind 32Bit Systeme von den Bugs auch betroffen.
Rein prophylaktisch: Ja, es gibt genügend Gründe noch einen 32Bit kernel zu fahren.
Ja und zwar mindestens, wenn leider nichts anderes vom Provider angeboten wird.
Tja, meine Lieblings-Distro ist in der 32bit-Variante istalliert und daher auch betroffen, und meine Zweit-Distri (Lubuntu64) hat noch keinen gefixten Kernel ausgerollt.
Also wird erst mal mit abgeschaltetem Javascript gesurft, und nach dem Lubuntu-Update werde ich wohl erst mal auf Lubuntu64 ausweichen müssen.
Wenn keine gepatchten 32bit-Kernel vorliegen sollten, dann liegt das eher an der Distribution.
Es sei denn, die neuen 32bit-2.6.32-Kernel für CentOS6 (und damit für RHEL6) wären im Bezug auf Meltdown reiner Fake, was ich nicht annehme:
https://lists.centos.org/pipermail/centos-announce/
2018-January/022701.html
Zudem ist aktuell zuwenig über die konkrete Art und Weise der Betroffenheit von alten 32bit-Systemen im Hinblick auf Meltdown und Spectre bekannt. Das Gemixe zwischen Kernel- und Userland-Speicheradressen unterliegt dort zum einen meist den Regularien des 1GB-/3GB-RAM-Splits (das erst 1GB für den Kernel (low-memory area), die folgenden 3GB für Userland-Speicheradressen) und zum anderen könnte man u.U. mit einem Abschalten des CPU-L1-Caches zumindest Meltdown entgegenwirken.
Ob das aber wirklich so zutrifft, weiß ich allerdings momentan nicht.
Die momentane Funkstille bei Intel im Hinblick auf die Betroffenheit der 32bit-Intelsysteme etwa mit Meltdown ist IMO unerhört. Intel glaubt tatsächlich, dass Sie mit der Strategie durchkommen werden, nur die CPUs mit Software-Updates (u.a. Microcode-Updates) zu versorgen, die seit 2013 gebaut wurden. Alle älteren CPUs wären somit quasi von Intel "aufgegeben".
Beim Ubuntu-Kernelupdate für Kernel 4.13 ist das aber exakt so. Nach dem Update sagt der weiter oben verlinkte Exploit-Test immer noch: "Vulnerable!"
Und auch bei Kernel 4.14.12 direkt von Kernel.org hängt der Parameter für das Schließen der Lücke vom 64bit-Modus ab. Stellt man auf 32 bit um, ist der Parameter aus der Kernel-Menü-Konfiguration ausgeblendet.
Du lagst leider richtig.
Ein Suse-Entwickler hat nun die ersten 32bit-Patches für Meltdown eingereicht:
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/00657.html
Interessant ist dabei, dass aufgrund der unter 32bit noch vorhandenen Segmente Segmentierung selbst ausreicht, weshalb PTI wie unter 64bit gar nicht notwendig ist (64bit macht keinen Gebrauch mehr von dieser Segmentierung). Man kann dabei die Segmentsgrenzen so setzen, dass kein Zugriff auf Kernel-Speicheradressen möglich ist. 32bit wäre dann per Segmentierung gegen Meltdown geschützt, der Performance Hit für 32bit wäre dann bei 0%.
Es muss also niemand seine PIII-, Pentium M- oder PIV-CPU gegen einen PentiumI- oder 32bit-AMD-Prozessor austauschen, um vor Meltdown unter 32bit geschützt zu sein.
Gegenwärtig wird abgecheckt, ob es 32bit-Hardware auf irgendeiner Architektur gibt, die hier Probleme macht und die dann vielelicht doch PTI braucht.