Kurze Frage zu "ucode-intel"

Hinweis: In dem Thema Kurze Frage zu "ucode-intel" gibt es 31 Antworten auf 4 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Weil es immer noch niemand glaubt:
    Das "böse" Intel Update der Firmware gelangt NICHT zu irgenwelchen Paketbauern irgendwelcher Distributionen.
    Die erhalten NUR OEMs (OriginalEqipmentManufacturer) und noch einige "Bios"- Hersteller.


    Updates, die wir kriegen, haben damit nur peripher zu tun.


    Bei wem das Paket ohne Ärger läuft, der sollte es auch drauf lassen.

  • Weil es immer noch niemand glaubt:
    Das "böse" Intel Update der Firmware gelangt NICHT zu irgenwelchen Paketbauern irgendwelcher Distributionen.
    Die erhalten NUR OEMs (OriginalEqipmentManufacturer) und noch einige "Bios"- Hersteller.

    Der CPU-Microcode wird hier in die Mainboard-Firmware integriert und als BIOS/UEFI-Update verteilt.


    Updates, die wir kriegen, haben damit nur peripher zu tun.

    Es gibt aber nur einen neuen fehlerhaften Intel-CPU-Microcode. Ob der auf dem Mainboard gespeichert ist oder auf der Festplatte spielt keine Rolle.


    Bei wem das Paket ohne Ärger läuft, der sollte es auch drauf lassen.

    Kannst du das „sollte“ auch begründen?
    Oder: Warum klammerst du dich wie ein Ertrinkender an einen fehlerhaften CPU-Microcode von Intel?

    Für den Inhalt des Beitrages 117837 haftet ausdrücklich der jeweilige Autor: Agnes

  • Keine Linuxdistribution liefert irgendwelche Firmware Updates für das BIOS oder UEFI.
    Das würde voraussetzen, dass die Distris alle Geheimnisse des Boards kennen würden. Dem ist nicht so.
    Es werden von openSUSE (und allen anderen Distris auch) ausschließlich Firmware Updates geliefert, die beim Bootvorgang beim Laden des Kernels gezogen werden.


    Dass das Intel Firmware Update bei einigen Prozessoren zu erratische Verhalten führt, heißt aber halt auch, dass es bei einigen anderen anständig läuft. Wenn es läuft: Finger weg! Uralte IT Weisheit.
    Ich hatte von Anfang an gesagt, dass dieser Hype eher schädlich ist, und einigen, die sich davon anstecken lassen, mächtig Ärger machen würde.
    Und ebenso habe ich von Anfang an gesagt, dass es dagegen kein Heilmittel gibt. Jedenfalls nicht heute und nicht morgen. Das wird lange dauern, weil sehr, sehr viele Applikationen umgeschrieben werden müssen.
    Ein wenig Firmwarebasteln ist keine Lösung.


    Die Updates von Linux für diese Lücken befassen sich nicht mit der Ursache des Problems, sondern versuchen lediglich die Angriffe möglichst zu erschweren. Intel will die Ursache abstellen, was ihnen so einfach nicht gelingen wird. Nicht auf die Schnelle, und nicht für alle betroffenen Prozessoren.
    Das sind zwei verschiedene Dinge. Auch wenn sie miteinander natürlich verschränkt sind.


    Und wie die wirklich zusammenhängen, kann niemand von uns sagen.
    Das können nur ein paar Leute bei Intel und AMD selbst. (Was ich auch schon geschrieben hatte, dass das für uns letztlich alles nur Blackbox ist, weil es die am strengsten gehüteten Firmengeheimnisse sind.)
    Die Leute, die bei Linux selbst Einblick in diese Dinge haben, testen natürlich auch alle Firmware Updates von Intel und AMD, da sie ja ihren Teil im Linuxkernel anpassen müssen. Sie basteln aber derzeit eher Würgarounds, und sind damit so beschäftigt, dass sie für unsere Fragen keine Zeit haben.


    Ich klammere mich also nicht an irgendwelche fehlerhafte Software.
    Ich weiß, dass jede Software unzählige Fehler enthält.
    Als vor zig Jahren WinWord 2.0 (noch zu Win95 Zeiten) auf den Markt kam, waren in der internen Fehlerdatenbank von Microsoft insgesamt gut 20.000 Fehler bekannt(, und die meisten Fehler mit "will not be fixed" markiert).
    Heute ist die Software wesentlich komplexer. Also haben wir es mit 1.600.000 bekannten Fehlern zu tun.


    Dieser Hype nervt einfach, und verleitet den durchschnittlichen User zu sehr bedenklichen Aktionen.
    Die Löcher existieren weiter. Davon völlig unabhängig.


    Und wenn nun das Linux Firmware Update auf einem Rechner läuft, dann läuft es eben. Wenn das bei anderen Boards zu Fehlern führt, sind diese anderen Systeme halt anfällig.
    Aber das laufende System läuft. Und dem ist es auch egal, wie empfindlich andere Konstellationen reagieren.

  • Ich denke und hoffe doch, dass der zypper dup-Befehl für Tumbleweed keine sehr bedenkliche Aktion darstellt :| (Unter Annahme, dass man seinen Repositories Vertrauen schenkt)


    Ich hatte auch keine Lust, das Paket mit nem Lock zu versehen... Jetzt ist es jedenfalls weg und ich will da auch erst mal nicht mehr dran rühren.


    Aber ich stimme dir zu, dass man sich mit zweifelhaften Aktionen zurück halten sollte. Die Gründe die du dazu genannt hast, finde ich auch absolut plausibel.

    Für den Inhalt des Beitrages 117848 haftet ausdrücklich der jeweilige Autor: Antarctris

  • Ich denke und hoffe doch, dass der zypper dup-Befehl für Tumbleweed keine sehr bedenkliche Aktion darstellt

    Für Tumbleweed ist gerade dieser Befehl richtig und nicht "zypper up"!


    https://lwn.net/Articles/717489/

  • Keine Linuxdistribution liefert irgendwelche Firmware Updates für das BIOS oder UEFI.

    Das habe ich mit keinem Wort geschrieben.


    Intel will die Ursache abstellen, was ihnen so einfach nicht gelingen wird. Nicht auf die Schnelle, und nicht für alle betroffenen Prozessoren.
    Das sind zwei verschiedene Dinge. Auch wenn sie miteinander natürlich verschränkt sind.


    Und wie die wirklich zusammenhängen, kann niemand von uns sagen.

    Das kann man schon seit 1 Woche im letzten Absatz nachlesen. https://www.pro-linux.de/news/1/25529/intel-rät-von-microcode-update-ab.html


    Das können nur ein paar Leute bei Intel und AMD selbst. (Was ich auch schon geschrieben hatte, dass das für uns letztlich alles nur Blackbox ist, weil es die am strengsten gehüteten Firmengeheimnisse sind.)
    Die Leute, die bei Linux selbst Einblick in diese Dinge haben, testen natürlich auch alle Firmware Updates von Intel und AMD, da sie ja ihren Teil im Linuxkernel anpassen müssen. Sie basteln aber derzeit eher Würgarounds, und sind damit so beschäftigt, dass sie für unsere Fragen keine Zeit haben.

    Hier kann man nachlesen, was man mit den 3 neuen CPU-Befehlen (IBPB, STIBP und IBRS), die im neuen Intel-CPU-Mircocode stecken, programmieren kann, um einen Schutz vor Sprectre Variante 2 Angriffen zu bekommen: https://lkml.org/lkml/2018/1/22/598


    Und hier kann man nachlesen, was Intel mit diesen neuen CPU-Befehlen da für Linux Kernel 4.16 als Patch eingereicht hat, und mit welch scharfen Worten Linus Torvalds diesen Intel-Code kritisiert hat: http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html


    Das ist alles nicht geheim oder eine Blackbox.


    Dieser Hype nervt einfach, und verleitet den durchschnittlichen User zu sehr bedenklichen Aktionen.

    So that's where the problem is.


    Der neue Intel CPU-Microcode stellt für sich allein Null Schutz vor Sprectre Variante 2 Angriffen dar. Und der neue Intel-Code, der auf den CPU-Microcode aufbaut, kommt eher nicht in den Kernel 4.16.


    Es gibt außerdem schon seit Anfang Januar eine Lösung, die von Google kommt und keine neuen CPU-Befehle benötigt: Return Trampoline (Retpoline).
    https://www.pro-linux.de/news/1/25508/retpoline-unterstützung-für-gcc-7.html
    Dieser Retpoline-Code steckt im jetzt erschienenen Linux Kernel 4.15, sowie 4.14.14 und 4.9.77.
    Er steckt aber leider nicht im Linux Kernel 4.4.112. Das kann man hier nachlesen: https://www.heise.de/ct/artike…4-15-3900646.html?seite=3


    Ich denke und hoffe doch, dass der zypper dup-Befehl für Tumbleweed keine sehr bedenkliche Aktion darstellt :| (Unter Annahme, dass man seinen Repositories Vertrauen schenkt)

    Du hast jetzt wieder den Intel-CPU-Microcode aus 2017 laufen. Was soll daran bedenklich sein? Du hat doch bestimmt einen Kernel laufen, der Retpoline schon implementiert hat.
    Der Nachteil von Retpoline ist halt, dass alle Anwendungen mit dem neuen GCC neu compiliert werden müssen. Unter Linux ist sowas aber doch kein Thema.

    2 Mal editiert, zuletzt von Agnes ()

    Für den Inhalt des Beitrages 117851 haftet ausdrücklich der jeweilige Autor: Agnes

  • Du hat doch bestimmt einen Kernel laufen, der Retpoline schon implementiert hat.

    Ich hoffe doch? Ich musste aber gerade feststellen, dass uname -r mir "4.14.15-1-default" sagt. Installiert sind 4.14.15-1.5 und 4.14.15-1.6. Ich hoffe mal er verwendet dann also letzteren.


    Wie kann ich das System dazu bringen mir nicht mehr so eine "-default"-Ungenauigkeit zu nennen? Hängt das mit grub zusammen? (Falls geüwnscht kann man dazu auch gerne ein eigenes Thema eröffnen..^^)

    Für den Inhalt des Beitrages 117852 haftet ausdrücklich der jeweilige Autor: Antarctris

  • Falls geüwnscht kann man dazu auch gerne ein eigenes Thema eröffnen.

    Das würde ich mal anregen, denn mit dem TE hat das alles nicht mehr viel zu tun. Zumal das Thema als erledigt gekennzeichnet wurde.

  • Ich hoffe doch? Ich musste aber gerade feststellen, dass uname -r mir "4.14.15-1-default" sagt. Installiert sind 4.14.15-1.5 und 4.14.15-1.6. Ich hoffe mal er verwendet dann also letzteren.

    Es passen doch beide Kernel. Ab Kernel 4.14.14 ist Retpoline implementiert.
    Schaue doch einfach mal nach, wie es hier beschrieben ist und poste die Ausgabe: https://www.pro-linux.de/news/…meltdown-und-spectre.html
    grep . /sys/devices/system/cpu/vulnerabilities/*


    Ohne passenden Intel-Patch-Code ist der Intel-CPU-Microcode witzlos. Aber will man den überhaupt haben, nach dem was Linus Torvalds dazu schreibt?

    Für den Inhalt des Beitrages 117856 haftet ausdrücklich der jeweilige Autor: Agnes

  • Achso, ich dachte das kam erst mit den letzten Kernel-Patches, ich sollte mich gründlicher informieren, entsprechende Links findet man hier ja schon genug. Wenn es also sowieso drin ist, wird es schon passen, das brauchen wir dann nicht weiter breit zu treten ;)


    Und ich mach mich dann mal schlauer :D

    Für den Inhalt des Beitrages 117857 haftet ausdrücklich der jeweilige Autor: Antarctris