klasie
Anmeldungsdatum: 7. August 2018
Beiträge: 523
Wohnort: BY
|
Hallo, ich habe soeben mein System überprüft, dabei ergab sich aus der Abfrage
tail /sys/devices/system/cpu/vulnerabilities/*
insbesondere das folgende Ergebnis
==> /sys/devices/system/cpu/vulnerabilities/srbds <==
Vulnerable: No microcode Ich dachte, das wäre längst behoben und frage mich, ob und was zu unternehmen ist. Kann jemand Auskunft geben? - Vielen Dank!
|
Kellerkind_2009
Anmeldungsdatum: 26. November 2009
Beiträge: 19610
Wohnort: Schleswig-Holstein
|
Hier sieht es so aus ==> /sys/devices/system/cpu/vulnerabilities/srbds <==
Not affected
*-cpu
Produkt: Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz
ii intel-microcode 3.20201110.0ubuntu0.20.10.2 amd64 Processor microcode firmware for Intel CPUs
|
klasie
(Themenstarter)
Anmeldungsdatum: 7. August 2018
Beiträge: 523
Wohnort: BY
|
Hi Stephan,
das mit "not affected" kommt bei mir erst eine Zeile danach im Zusammenhang mit 'tsx_async_abort'
==> /sys/devices/system/cpu/vulnerabilities/tsx_async_abort <==
Not affected Danke dir und schöne Weihnachten!
Klaus
|
Kellerkind_2009
Anmeldungsdatum: 26. November 2009
Beiträge: 19610
Wohnort: Schleswig-Holstein
|
Danke dir 😀 Wünsche ebenfalls ein Frohes Fest. Gruß Stephan
|
klasie
(Themenstarter)
Anmeldungsdatum: 7. August 2018
Beiträge: 523
Wohnort: BY
|
Nach weiteren Recherchen besteht der von mir vermutete Zusammenhang zwischen den Vulnerabilities 'SRBDS' und 'tsx_async_abort' nicht. Betroffen von der Anfälligkeit mit Blick auf SRBDS sind verschiedene (nicht alle) Intel-Prozessoren. Die vorgeschlagenen Mitigations durch Installation des hier näher bezeichneten Intel-Microcodes brachte auf meinem Rechner keine Änderung. - Zum Problem vgl. auch hier Es wäre schön, wenn sich Kubuntu-Nutzer zu Wort melden würden, bei denen das gleiche Problem besteht. Am besten natürlich mit einer Lösung. 😉 Edit: Mit Kubuntu 20.10 die gleiche Misere.
|
klasie
(Themenstarter)
Anmeldungsdatum: 7. August 2018
Beiträge: 523
Wohnort: BY
|
Ich habe mit dem Live-System Kubuntu 20.10 auf meinem Rechner mit einer i5-3340-CPU mit der oben bezeichneten Eingabe die Auskunft 'vulnerable - no microcode' erhalten. Der microcode hat die Versionsnummer 3.20200609.0ubuntu0.20.04.2. Mit dem gleichen Live-System habe ich einen Vergleichsrechner mit einer i5-4200-CPU gefüttert. Nach der erwähnten Eingabe erschien die Antwort 'Mitigation - microcode'. Die Versionsnummer des microcodes ist die gleiche wie vor. Die von der Vulnerability betroffenen Prozessoren sind hier gelistet. Wie kann es sein, dass ein und derselbe microcode einmal als Mitigation (an)erkannt wird, das andere mal nicht?
|
Kellerkind_2009
Anmeldungsdatum: 26. November 2009
Beiträge: 19610
Wohnort: Schleswig-Holstein
|
Moin Klaus, nicht das ich hier viel zu betragen kann – aber wenn ich mal sehe grep microcode /etc/modprobe.d/* und die Erklärung dazu lese Das Microcode-Modul versucht, ein Microcode-Update anzuwenden, wenn es automatisch geladen wird. Dies ist nicht immer sicher, daher wird es standardmäßig blockiert. wäre eine Idee das mal zu ändern.An meinem Laptop mit der Intel CPU hat es keine andere Ausgabe erzeugt. Gruß Stephan
|
klasie
(Themenstarter)
Anmeldungsdatum: 7. August 2018
Beiträge: 523
Wohnort: BY
|
Danke Stephan, das war schon ein wertvoller Hinweis. Ich habe daraufhin die aktuell vorhandene Microcode-Version ausgelesen und folgende Differenzen festgestellt:
kubuntu@kubuntu:~$ grep -E 'family|model|stepping|microcode' /proc/cpuinfo | head -5
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3340M CPU @ 2.70GHz
stepping : 9
microcode : 0x21 und kubuntu@kubuntu:~$ grep -E 'family|model|stepping|microcode' /proc/cpuinfo | head -5
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i5-4200 CPU @ 2.50GHz
stepping : 3
microcode : 0x28 Ich überlege jetzt, wie ich weitermache. Hier kommt noch die von Dir angeregte Ausgabe (alle vorstehenden Angaben sowie die nachstehende sind aus dem Live-System Kubuntu 20.10!):
kubuntu@kubuntu:~$ grep microcode /etc/modprobe.d/* # gleich bei i5-3340M und i5-4200
/etc/modprobe.d/amd64-microcode-blacklist.conf:# The microcode module attempts to apply a microcode update when
/etc/modprobe.d/amd64-microcode-blacklist.conf:blacklist microcode
/etc/modprobe.d/intel-microcode-blacklist.conf:# The microcode module attempts to apply a microcode update when
/etc/modprobe.d/intel-microcode-blacklist.conf:blacklist microcode
/etc/modprobe.d/iwlwifi.conf:# microcode file installed on the system. When removing iwlwifi, first Edit: die Ausgaben betreffend das fest installierte Kubuntu 20.04 (i5-3340M) sind identisch!
|
Kellerkind_2009
Anmeldungsdatum: 26. November 2009
Beiträge: 19610
Wohnort: Schleswig-Holstein
|
Moin Klaus, wie sieht denn bei dir die Ausgabe von sudo dmesg | grep microcode ? Vielleicht ist da was zu Entdecken.Bei mir hier sudo dmesg | grep microcode
[sudo] Passwort für stephan:
[ 0.000000] microcode: microcode updated early to revision 0x60f, date = 2010-09-29
[ 0.171299] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.696896] microcode: sig=0x10676, pf=0x80, revision=0x60f
[ 0.696948] microcode: Microcode Update Driver: v2.2.
grep -E 'family|model|stepping|microcode' /proc/cpuinfo | head -5
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz
stepping : 6
microcode : 0x60f Gruß Stephan
|
klasie
(Themenstarter)
Anmeldungsdatum: 7. August 2018
Beiträge: 523
Wohnort: BY
|
Servus Stephan, aus der Ausgabe kann ich Weiteres nicht erkennen:
klasie@klasie-Latitude-E6430:~$ sudo dmesg | grep microcode
[sudo] Passwort für klasie:
[ 0.112227] SRBDS: Vulnerable: No microcode
[ 0.568012] microcode: sig=0x306a9, pf=0x10, revision=0x21
[ 0.568069] microcode: Microcode Update Driver: v2.2.
klasie@klasie-Latitude-E6430:~$ Ich habe auch schon verschiedene Ausgaben der 'Intel Microcode Revision Guidance' durchsucht, kann aber keine aktuellere Version als die 21 bzw. 0x21 finden (CPUID = 306A9). Die von Ubuntu zitierte Version 'intel-microcode 3.20200609.0ubuntu0.20.04.2' sollte gemäß der Änderungsliste in der Paketverwaltung bereits berücksichtigt sein.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
klasie schrieb: […] Die von der Vulnerability betroffenen Prozessoren sind hier gelistet. Wie kann es sein, dass ein und derselbe microcode einmal als Mitigation (an)erkannt wird, das andere mal nicht?
Zunächst einmal zur Klärung des Begriffs: Wer das Wort „Mitigation“ verwendet, will oft damit den Eindruck erwecken, dass ein Mangel an der Sache beseitigt wird. Tatsächlich geht es aber nur um eine Abschwächung/Milderung/Linderung der tatsächlichen oder möglichen Folgen dieses Mangels. In dieser Diskussion besteht der Mangel in einem bestimmten unerwünschten Verhalten von CPUs. Welche CPUs des Herstellers Intel betroffen sind, kann man der oben verknüpften Seite entnehmen. Zur Anwendung dieser Seite muss man die eigene CPU identifizieren, z.B. so: $ grep -e family -e model -e step /proc/cpuinfo
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
stepping : 9 liefert die Familie, Modellreihe und Modell der CPUs als Dezimalzahlen. Zur Anwendung der Tabelle sind diese in Hex-Zahlen zu wandeln, das ergibt im konkreten Beispiel Family_Model = 06_3AH und also: Ja, diese CPU zeigt dieses unerwünschte Verhalten. Für family/model/stepping=6/60/3 (i5-4200) erhält man 06_3CH mit der gleichen Antwort. Gelindert soll der Mangel durch Einspielen von Mikrocode. Diesen kann nur der Hersteller der CPU erstellen. Da im Extremfall jede CPU eine eigene Medizin benötigt, wird der Hersteller zuerst die aktuell zum Verkauf stehenden nachbessern und sich dann den früheren Modellen zuwenden bis er an diesem Tun die Lust verliert oder für sich keinen wirtschaftlichen Vorteil mehr erwartet. Es kann also gut sein, dass für die eine CPU bereits ein Mikrocode zur Mitigation veröffentlicht wurde und für die andere noch nicht. Wenn Mikrocode verfügbar ist, muss er noch auf die CPU eingespielt werden. Das kann geschehen Im Falle des Linux-Kernels muss der Mikrocode natürlich in ein Software-Paket gepackt werden. Es kann sein, dass der Mikrocode zwar für eine bestimmte CPU vom Hersteller veröffentlicht, aber noch nicht per Paket-Management verteilt wurde. Da letztlich der Mikrocode für die CPU in ein Kernel-Modul (welches bei Ubuntu fest in den Kernel eingebaut ist) eingebracht wird, hängt es auch von der Kernel-Version ab, ob die Mitigation verfügbar ist oder nicht. Manchmal kommt es bei solchen Mikrocode-Aktualisierungen zu unerwünschten Nebeneffekten, z.B. die CPU startet unter seltenen Umständen nicht mehr. Dann wird der veröffentlichte Mikrocode vom Hersteller zurückgerufen (oder auch nicht), aber jedenfalls aus den Softwarepaketen wieder entfernt.
Was konkret bei dem hier diskutierten Fehler zutrifft, weiß ich auch nicht. Der berichtete Zustand ist zwar ärgerlich, scheint aber dem momentan üblichen/vorgesehenen/normalen zu entsprechen. Wenn man es weiter aufklären will, lohnt vielleicht ein Studium des Changelog des Paketes intel-microcode.
|
klasie
(Themenstarter)
Anmeldungsdatum: 7. August 2018
Beiträge: 523
Wohnort: BY
|
Danke für Deine Ausführungen @kB
|
Zuck
Anmeldungsdatum: 9. Juli 2020
Beiträge: 192
|
klasie schrieb: kubuntu@kubuntu:~$ grep microcode /etc/modprobe.d/* # gleich bei i5-3340M und i5-4200
/etc/modprobe.d/amd64-microcode-blacklist.conf:# The microcode module attempts to apply a microcode update when
/etc/modprobe.d/amd64-microcode-blacklist.conf:blacklist microcode
/etc/modprobe.d/intel-microcode-blacklist.conf:# The microcode module attempts to apply a microcode update when
/etc/modprobe.d/intel-microcode-blacklist.conf:blacklist microcode
/etc/modprobe.d/iwlwifi.conf:# microcode file installed on the system. When removing iwlwifi, first
}}} Edit: die Ausgaben betreffend das fest installierte Kubuntu 20.04 (i5-3340M) sind identisch!
Dazu habe ich das gefunden:
intel-microcode (3.20140913.1) unstable; urgency=low
+ modprobe.d: blacklist microcode module from autoloading outside
of the initramfs. Still load it inside the initramfs for logging
Quelle - Debian-Changelog https://packages.debian.org/sid/intel-microcode Der Intel-Microcode ist, sowie ich das verstanden habe, im Kernel einkompiliert(Built-in microcode) und wird "early loader" geladen. Der Microcode von außerhalb wird auf die blacklist gesetzt. Der Microcode von außerhalb wollte natürlich angewandt werden, weshalb diese Meldung erscheint. So meine Vermutung bzw. sowie ich mir das denke. Dazu noch eine paar Quellen zum einlesen.
https://wiki.archlinux.org/index.php/microcode
https://www.kernel.org/doc/html/latest/x86/microcode.html
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Zuck schrieb: […] Quelle - Debian-Changelog https://packages.debian.org/sid/intel-microcode
Das betrifft Debian und ist für Ubuntu daher höchstens indirekt von Relevanz. Wenn schon, sollte man sich auf der Ubuntu-Seite zum intel-microcode informieren: https://launchpad.net/ubuntu/+source/intel-microcode Hier kann man sich auch über die lustigen Bugs informieren, welche man sich beim Hantieren mit diesem Zeugs einfangen kann.
Der Intel-Microcode ist, sowie ich das verstanden habe, im Kernel einkompiliert(Built-in microcode) und wird "early loader" geladen.
Bei Ubuntu-Kerneln: Ja. Linux-Kernel anderer Distributionen können anders konfiguriert sein.
Der Microcode von außerhalb wird auf die blacklist gesetzt. […]
Da bei Ubuntu das Modul intel-microcode fest in den Kernel eingefügt ist, sind blacklist-Vermerke für modprobe & Co. ohne jeglichen Sinn. Sie werden ignoriert, weil es niemanden gibt, der sie ignorieren könnte. Und auch niemanden, der sie beachten könnte.
https://wiki.archlinux.org/index.php/microcode
Kann man lesen. Betrifft allerdings nicht Ubuntu.
https://www.kernel.org/doc/html/latest/x86/microcode.html
Kann man auch lesen.
|
klasie
(Themenstarter)
Anmeldungsdatum: 7. August 2018
Beiträge: 523
Wohnort: BY
|
Aus meiner Sicht muss in einem ersten Schritt überhaupt eine (aktualisierte) Version des Microcodes vom CPU-Hersteller vorliegen. In meinem Fall wäre das eine Version >21. Ob, wie und wie rasch diese neue Version vom BS-Hersteller (oder im Rahmen eines BIOS-updates vom PC-Hersteller) umgesetzt wird, kann sich frühestens in einem zweiten Schritt zeigen. Allerdings ist zu beachten, dass eine überarbeitete Version auch direkt von den Internetseiten des CPU-Herstellers (hier: Intel) installiert werden kann, sobald eine solche tatsächlich vorliegt. Das Vorgehen zu erklären würde allerdings den Rahmen dieses Threads sprengen.
|