lama4linux
Anmeldungsdatum: 17. November 2016
Beiträge: 131
|
Danke fürs Nachschlagen!
Habe nun mit sudo apt-get install intel-microcode=3.20180108.0~ubuntu16.04.2 die alte Version zurückgeholt und das Aktualisieren des Paketes vorerst unterbunden mit
sudo apt-mark hold intel-microcode Letzteres sollte sich mit sudo apt-mark unhold intel-microcode zu einem späteren Zeitpunkt leicht wieder aufheben lassen. Zurück bei der älteren Version $ apt list -a "intel-microcode"
Auflistung... Fertig
intel-microcode/xenial-security 3.20180108.0+really20170707ubuntu16.04.1 amd64 [aktualisierbar von: 3.20180108.0~ubuntu16.04.2]
intel-microcode/xenial-updates,now 3.20180108.0~ubuntu16.04.2 amd64 [Installiert,aktualisierbar auf: 3.20180108.0+really20170707ubuntu16.04.1]
intel-microcode/xenial 3.20151106.1 amd64
$ dmesg | grep microcode
[ 0.000000] microcode: CPU0 microcode updated early to revision 0xc2, date = 2017-11-16
[ 0.085755] microcode: CPU1 microcode updated early to revision 0xc2, date = 2017-11-16
[ 0.721643] microcode: CPU0 sig=0x506e3, pf=0x2, revision=0xc2
[ 0.721646] microcode: CPU1 sig=0x506e3, pf=0x2, revision=0xc2
[ 0.721661] microcode: CPU2 sig=0x506e3, pf=0x2, revision=0xc2
[ 0.721679] microcode: CPU3 sig=0x506e3, pf=0x2, revision=0xc2
[ 0.721737] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
lama4linux schrieb: Habe nun mit […] die alte Version zurückgeholt und das Aktualisieren des Paketes vorerst unterbunden […]
Warum? Dass das Paket zurückgezogen wurde hat ja einen Grund, die machen das ja nicht zum Spaß.
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
ok, das sieht ja dann schon besser aus. Wenn es keine reboot-probleme macht, dann ist es sicherer den microcode rev c2 zu verwenden. Intel schlägt das auch vor. Im launchpad bug steht, dass es wegen der berichteten reboot-Probleme mit einigen CPUs zurückgezogen wurde. Übrigens gibt es nun eine Liste von Intel, in der darauf hingewiesen wird für welche CPUs der microcode NICHT die mitigation von spectre v2 mitbringt. Microcode revision list – client | 22. 01. 2018
|
lama4linux
Anmeldungsdatum: 17. November 2016
Beiträge: 131
|
Developer92 schrieb: lama4linux schrieb: Habe nun mit […] die alte Version zurückgeholt und das Aktualisieren des Paketes vorerst unterbunden […]
Warum? Dass das Paket zurückgezogen wurde hat ja einen Grund, die machen das ja nicht zum Spaß.
Bei mir lief es stabil. Ich habe bisher keinen Systemabsturz gehabt, keine Probleme beim Rauf- oder Runterfahren. Einen Grund für den Wechsel zur alten Version kann ich nicht erkennen. Ich sehe deshalb nicht ein, mein System wieder anfälliger zu machen. Sollte in ein paar Tagen oder Wochen ein aktuelles Paket veröffentlicht werden, werde ich selbstverständlich die Aktualisierung wieder erlauben.
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
Die Empfehlungen Intels haben sich nun ins Gegenteil verkehrt. Intel ruft Microcode-Updates zurück. microcode revision guidance | Intel | January 22 2018 Meltdown und Spectre: Intel zieht Microcode-Updates für Prozessoren zurück | by Christof Windeck | heise | 22.01.2018 20:18 Uhr Der erste Absatz liest sich dennoch anders. Es ist nicht ganz klar, ob Intel oder die Distributoren dazu raten:
Noch größeres Chaos bei den Sicherheitslücken in Intel-Prozessoren: Weil Updates im manchen Fällen Probleme verursachen, rät Intel von der Installation ab; unter anderem HPE, Ubuntu, Red Hat und VMware ziehen Updates zurück.
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
Warum zieht hier ubuntu MEIN update zurück?!?!?!?111111 OMG!!!!
ganz einfach: Intel hat das Microcode-Update zurückgezogen, weil es nicht richtig läuft: https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/ Einfach mal abwarten, bis Intel selber das Ding im Griff hat. Oder halt einen AMD kaufen.
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
k1l, danke. Damit ist klar, dass das von Intel ausgeht, hatte zuvor noch gelesen, dass sie den µcode trotz der Probleme, wegen der höheren Sicherheit empfehlen. Entweder war die Info falsch, oder sie haben ihre Meinung dazu geändert.
|
Floridaboy
Anmeldungsdatum: 13. Februar 2015
Beiträge: 184
|
Blickt man da überhaupt noch durch??? floogy schrieb: Übrigens gibt es nun eine Liste von Intel, in der darauf hingewiesen wird für welche CPUs der microcode NICHT die mitigation von spectre v2 mitbringt. Microcode revision list – client | 22. 01. 2018
Da sind CPUs der neusten Generation dabei... Ich gehe davon aus, dass die Liste die NICHT-UNTERSTÜTZTEN Prozessoren sind?!?!
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
Noch nicht. Die werden irgendwann wahrscheinlich (besser) funktionierende microcodes ausliefern, oder auf retpoline setzen, der für spectre v2 keinen microcode benötigt und kaum Performanceeinbuße zeigt, wenn ich das richtig verstehe.
|
Floridaboy
Anmeldungsdatum: 13. Februar 2015
Beiträge: 184
|
Also beim Rechner meiner Freundin sind die CPU-Bugs noch da, wenn ich das richtig verstehe: $ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 55
model name : Intel(R) Celeron(R) CPU N2940 @ 1.83GHz
stepping : 8
microcode : 0x829
cpu MHz : 1832.600
cache size : 1024 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 3665.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 55
model name : Intel(R) Celeron(R) CPU N2940 @ 1.83GHz
stepping : 8
microcode : 0x829
cpu MHz : 1832.600
cache size : 1024 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 3665.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 55
model name : Intel(R) Celeron(R) CPU N2940 @ 1.83GHz
stepping : 8
microcode : 0x829
cpu MHz : 1832.600
cache size : 1024 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 3665.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 55
model name : Intel(R) Celeron(R) CPU N2940 @ 1.83GHz
stepping : 8
microcode : 0x829
cpu MHz : 1832.600
cache size : 1024 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 3665.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management: floogy schrieb: Welche ID hat die CPU?
cpuid | grep "processor serial number" | head -n1
dpkg -l intel-microcode | grep ^ii
iucode_tool -S -l /lib/firmware/intel-ucode/
Der CPUID-Befehl wirft bei mir nur ein "false" aus. Bei IUCODE_TOOL könnte man die ID herauslesen...: $ cpuid | grep "processor serial number" | head -n1
processor serial number = false
$ dpkg -l intel-microcode | grep ^ii
ii intel-microcode 3.20180108.1 amd64 Processor microcode firmware for Intel CPUs
$ iucode_tool -S -l /lib/firmware/intel-ucode/
iucode_tool: system has processor(s) with signature 0x00030678 Aber wie du schon geschrieben hast, ist da wohl noch kein Patch draußen. Viele Grüße, Floridaboy
|
chris34
Ikhaya- und Webteam
Anmeldungsdatum: 22. Oktober 2010
Beiträge: 3806
|
Floridaboy schrieb: Also beim Rechner meiner Freundin sind die CPU-Bugs noch da, wenn ich das richtig verstehe: $ cat /proc/cpuinfo
…
bugs : cpu_meltdown spectre_v1 spectre_v2
Nunja, die Ausgabe bedeutet nur, dass die CPU von dem Bug/Fehler betroffen ist – unabhängig davon, ob Softwarepatches dafür eingespielt wurden oder nicht. Der Befehl aus 8930291 sollte mehr Infos darübergeben, gegen was Patches vorhanden sind. Aber pin mich nicht drauf fest, ob das Canonical in einen älteren Kernel als 4.14 zurückportiert hat. Viele Grüße Chris
|
Floridaboy
Anmeldungsdatum: 13. Februar 2015
Beiträge: 184
|
Ah okay!
Hier mal die Ausgabe von:
$ grep . /sys/devices/system/cpu/vulnerabilities/*
grep: /sys/devices/system/cpu/vulnerabilities/*: Datei oder Verzeichnis nicht gefunden Somit wohl noch nichts...
|
chris34
Ikhaya- und Webteam
Anmeldungsdatum: 22. Oktober 2010
Beiträge: 3806
|
Floridaboy schrieb: Somit wohl noch nichts...
Ok, die schöne Funktion hat Canonical scheinbar dann nicht zurückportiert. Wenn man sicher gehen will, hilft dann im Zweifel nur selber in der Tabelle nachschlagen 🇬🇧. Im dort verlinkten USN für deine Ubuntu-Version schauen, ab welcher Kernel-Version das gefixt ist und mit der lokalen installierten Kernel-Version vergleichen. Viele Grüße Chris
|
Rosika
Anmeldungsdatum: 26. Februar 2016
Beiträge: 1355
|
Hallo zusammen, ich verfolge die meldown- und spectre-Diskussion hier schon die ganze Zeit und bin u.a. durch Euch auf den meltdown- und spectre-Checker gestoßen.
Den kann man sich ja auf der Seite https://github.com/speed47/spectre-meltdown-checker herunterladen. Das finde ich im Prinzip eine tolle Sache, und so wollte ich diesen Checker auch benutzen. Ich bin aber nicht ganz sicher, ob ich das tun soll, da man den
ja mit "sudo" laufen lassen soll. Deswegen möchte ich hier nachfragen, ob jemand eine Ahnung hat, inwieweit man den gefahrlos ausführen kann. Bei Skripten aus dem Internet, die root-Rechte
benötigen, überlege ich mir das immer zweimal.
Was sind Eure Erfahrungen, bzw. Meinungen dazu? Vielen Dank im voraus. LG
Rosika ☺ P.S.:
Ich nutze Lubuntu 16.04.3 LTS, 64 bit
|
floogy
Anmeldungsdatum: 21. Juli 2006
Beiträge: 3288
Wohnort: Koblenz
|
Ich habe das Skript auch schon angewendet. Es wird von einigen mir seriös erscheinende Seiten angeführt. Der Code sieht nach einem flüchtigen Blick nicht besorgniserregend aus, obwohl ich mich hier nicht zu weit aus dem Fenster lehnen will. Man kann ihn hier einsehen und selbst überprüfen: https://github.com/speed47/spectre-meltdown-checker/blob/master/spectre-meltdown-checker.sh Es gibt ein weiteres Tool von Red Hat: https://access.redhat.com/labsinfo/speculativeexecution https://ubuntuforums.org/showthread.php?t=2381801&page=16 https://www.howtogeek.com/338801/how-to-check-if-your-pc-is-protected-against-meltdown-and-spectre/ https://www.sandata.net/main.asp?VID=1&lng=1&kat1=123&kat2=804&T__=Meltdown-+amp;-Spectre https://www.techrepublic.com/article/how-to-tell-if-your-linux-machine-is-patched-against-meltdown-and-spectre/
Ein Problem mag sein, dass es nicht alle Fälle eindeutig erfasst, und z.B. bei nicht betroffenen CPUs unter Umständen Alarm schlägt, oder in falsche Sicherheit wiegt. Es liegt aktuell in der version v0.33 vor, der verlinkte Beitrag (letzter Post) bezieht sich möglicherweise auf eine ältere Version des Skripts: https://www.pclinuxos.com/forum/index.php/topic,144894.msg1238168.html?PHPSESSID=tpfil22gt3ht0hot2ral4qnrf5#msg1238168
Der Kernel-Entwickler Greg Kroah-Hartman empfiehlt auf seinem Blog http://www.kroah.com/log/ diese Methode, die allerdings noch nicht bei allen Kerneln implementiert ist:
Is my machine vunlerable? For this question, it’s now a very simple answer, you can check it yourself. Just run the following command at a terminal window to determine what the state of your machine is: | $ grep . /sys/devices/system/cpu/vulnerabilities/*
|
On my laptop, right now, this shows: | $ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline
|
This shows that my kernel is properly mitigating the Meltdown problem by implementing PTI (Page Table Isolation), and that my system is still vulnerable to the Spectre variant 1, but is trying really hard to resolve the variant 2, but is not quite there (because I did not build my kernel with a compiler to properly support the retpoline feature). If your kernel does not have that sysfs directory or files, then obviously there is a problem and you need to upgrade your kernel!
|