robert-engel
Anmeldungsdatum: 30. Oktober 2015
Beiträge: 1968
|
Mal ganz kurz gefragt: re@PC:~$ dmesg | grep -i microcode
[ 0.000000] microcode: CPU0 microcode updated early to revision 0x80, date = 2018-01-04
[ 0.090183] microcode: CPU1 microcode updated early to revision 0x80, date = 2018-01-04
[ 0.094498] microcode: CPU2 microcode updated early to revision 0x80, date = 2018-01-04
[ 0.098781] microcode: CPU3 microcode updated early to revision 0x80, date = 2018-01-04
[ 0.770164] microcode: CPU0 sig=0x906e9, pf=0x2, revision=0x80
[ 0.770201] microcode: CPU1 sig=0x906e9, pf=0x2, revision=0x80
[ 0.770220] microcode: CPU2 sig=0x906e9, pf=0x2, revision=0x80
[ 0.770298] microcode: CPU3 sig=0x906e9, pf=0x2, revision=0x80
[ 0.770339] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba Wäre das so erstmal in Ordnung? Ich habe einen i5-7500 und Ubuntu 16.04.3 mit Kernel 4.4.0-109. Danke, Robert.
|
fandPfand
Anmeldungsdatum: 28. Oktober 2017
Beiträge: 83
|
Hallo robert-engel, dass spectre schon im microcode gepatcht ist, kann ich mir nicht vorstellen. Aber meltdown könnte bei Dir jetzt doppelt "abgewürgt" sein (microcode und kernel).
Neugierig wie ich bin, würde mich jetzt folgende Ausgabe interessieren:
lscpu | grep -iE "pti|kaiser"; dmesg | grep -i isolation; dmesg | grep -i microcode; dpkg --list | grep -i microcode Und das ganze natürlich 2x: Also mit dem 4.4.0-109 und einem alten, ungepatchten Kernel (falls Du so einen noch drauf hast und da schnell mal reinbootest).
Sollte der ungepatchte Kernel mit dem aktuellen microcode nämlich auch schon z.B.
Kernel/User page tables isolation: enabled
ausspucken, würde ich das dann dem microcode zuordnen.
|
robert-engel
Anmeldungsdatum: 30. Oktober 2015
Beiträge: 1968
|
Hallo fandPfand, danke für Dein Interesse. re@PC:~$ lscpu | grep -iE "pti|kaiser"; dmesg | grep -i isolation; dmesg | grep -i microcode; dpkg --list | grep -i microcode
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 pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch invpcid_single intel_pt kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
[ 0.000000] Kernel/User page tables isolation: enabled
[ 0.000000] microcode: CPU0 microcode updated early to revision 0x80, date = 2018-01-04
[ 0.090183] microcode: CPU1 microcode updated early to revision 0x80, date = 2018-01-04
[ 0.094498] microcode: CPU2 microcode updated early to revision 0x80, date = 2018-01-04
[ 0.098781] microcode: CPU3 microcode updated early to revision 0x80, date = 2018-01-04
[ 0.770164] microcode: CPU0 sig=0x906e9, pf=0x2, revision=0x80
[ 0.770201] microcode: CPU1 sig=0x906e9, pf=0x2, revision=0x80
[ 0.770220] microcode: CPU2 sig=0x906e9, pf=0x2, revision=0x80
[ 0.770298] microcode: CPU3 sig=0x906e9, pf=0x2, revision=0x80
[ 0.770339] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
ii intel-microcode 3.20180108.0~ubuntu16.04.2 amd64 Processor microcode firmware for Intel CPUs
ii iucode-tool 1.5.1-1ubuntu0.1 amd64 Intel processor microcode tool
re@PC:~$ Hier die gewünschte Auskunft. Ich habe nur noch den Kernel 4.4.0-108, der bei mir (die paar Stunden, die er im Einsatz war) keine Probleme bereitet hat. Ich hatte aber vorher schonmal nach der kernel isolation geschaut. Die war beim vorherigen Kernel (ich glaube der 104er) nicht verfügbar, beim 108er und 109er aber bereits vor der Installation des Microcode vorhanden. Gruß, Robert.
|
fandPfand
Anmeldungsdatum: 28. Oktober 2017
Beiträge: 83
|
robert-engel schrieb:
Ich hatte aber vorher schonmal nach der kernel isolation geschaut. Die war beim vorherigen Kernel (ich glaube der 104er) nicht verfügbar, ...
Tja, das wäre genau das Interessante gewesen: Hätte der alte Kernel mit dem bei Dir sehr aktuellen microcode (2018-01-04) eben auch schon die "isolation" gebracht, hätte ich gesagt: Ja, meltdown wird bereits von dem microcode erschwert oder idealerweise eliminiert. So weiss man's halt leider nicht, wer alles (kernel und/oder microcode) für die "isolation" beigetragen hat.
Trotzdem danke. Nach meiner auf Halbwissen basierenden Einschätzung ist Dein Rechner so gut abgesichert, wie es z.Zt. möglich ist. Browser halt noch updaten bzw. ggf. absichern (siehe hier: https://ikhaya.ubuntuusers.de/2018/01/08/meltdown-und-spectre/), Browser-Verhalten anpassen, mehr fällt mich nicht ein. Was "draußen" auf den Servern los ist, da kann man nur spekulieren und hat ohnehin keinen Einfluss. Ganz interessant für Leute, die einigermaßen Englisch können, ist vielleicht auch der "sticky" bei https://ubuntuforums.org/showthread.php?t=2381801
Auf Seite 6 wird auch ein "spectre-meltdown-checker" auf github erwähnt, der soweit ich es einschätzen kann, anhand der systeminfos eine Prognose zu spectre und meldown erstellt. Ich kriege immer Zahnweh, sowas mal auszuprobieren (script kapiere ich nicht und es will sudo!), aber bisher gab es auf dem Forum keinen Aufschrei gegen das script, also wer Mut hat... (und ggf. ein gutes backup 😈 ...)
|
robert-engel
Anmeldungsdatum: 30. Oktober 2015
Beiträge: 1968
|
Einstweilen vielen Dank. Von dem Skript habe ich auch schon gelesen ...
|
burli
Anmeldungsdatum: 27. April 2007
Beiträge: 9000
Wohnort: Petersberg
|
Bin ja mal gespannt, wie die Geschichte ausgeht. Bei der Anzahl an Computern, die teilweise noch mit alten Betriebssystemen laufen oder nicht mehr aktualisiert werden können, kann da noch einiges passieren. Nur gut, dass meine letzte CPU von AMD war. Und ich hatte vor, mir eine neue zu kaufen. Das werde ich jetzt wohl verschieben, bis eine neue Generation auf den Markt kommt. Wird wohl eine Weile dauern. Bin auch mal gespannt, ob die Preise und Verkaufszahlen fallen.
|
V0LKER
Anmeldungsdatum: 23. Februar 2014
Beiträge: 1967
|
Hallo, laut https://www.golem.de/news/updates-wie-man-spectre-und-meltdown-loswird-1801-132125-8.html ist der Microcode seit 8.1.2018 von Intel raus Zitat von Golem:
Um auch gegen die zweite Variante von Spectre (CVE-2017-5715) geschützt zu sein, sollten Linux-Nutzer auf jeden Fall Mikrocode-Updates für ihre jeweilige Plattform einspielen, sofern diese bereits zur Verfügung stehen. Intel hat den aktualisierten Mikrocode am 8. Januar veröffentlicht und die meisten Distributionen sollten diesen bereits als Paket bereitstellen. Notwendig wird ein Mikrocode-Update außerdem für die neue Zen-Architektur von AMD. Ob dies Ryzen und Epyc gleichermaßen betrifft, ist derzeit nicht bekannt. Um hier Mikrocode-Updates einspielen zu können, sind einige vorbereitenden Kernel-Patches notwendig, die in den aktuellen Upstream-Kernel bereits verfügbar sind.
Die Datumsanzeige bei div Anfragen ist wohl irreführend, wie oben 2018-1-4 Intel brachte den Code erst 2018-1-8 raus. Bearbeitet von Developer92: Zitatsyntax für Zitat eingefügt.
|
Reinarden
Anmeldungsdatum: 29. September 2014
Beiträge: 1044
|
Mit dem von Fandpfand referenzierten, gut bekanntem Script, welches nichts am System verändert, sondern nur Kernel-Dateien usw. analysiert: https://github.com/speed47/spectre-meltdown-checker/blob/master/spectre-meltdown-checker.sh … sehen wir nun eben praktisch, was wir schon theoretisch wußten:
Wir Benutzer mit Intel-Prozessoren älter als fünf Jahre, also die große Mehrheit, sind wegen – bisher – fehlenden Microcode-Aktualisierungen seitens Intel :
nicht gegen #1 Spectre nicht gegen #2 Spectre nur gegen #3 Meltdown.
geschützt. Zu AMD kann ich momentan nichts sagen, da ich gerade nur Zugriff auf Intel-Rechner habe. Wenig tröstlich für Benutzer kompromitierter Hardware ist, daß Spectre deutlich komplizierter und nicht so einfach auszunutzen sei als Meltdown, und, bis es Malware für diese Spectre-Schwachstelle geben wird, es deshalb sicher etwas länger dauern werde. Um einen effektiven Angriff zu programmieren, müsse sehr großer Aufwand betrieben werden. (so zitiert Heise einen der Finder der Sicherheitslücken.)
|
swkh
Anmeldungsdatum: 10. April 2015
Beiträge: 610
|
Reinarden schrieb: Mit dem von Fandpfand referenzierten, gut bekanntem Script, welches nichts am System verändert, sondern nur Kernel-Dateien usw. analysiert:
... Zu AMD kann ich momentan nichts sagen, da ich gerade nur Zugriff auf Intel-Rechner habe.
Zu meinem AMD-Rechner ergibt sich folgendes: Spectre and Meltdown mitigation detection tool v0.28
Checking for vulnerabilities against running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
CPU is AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO
> STATUS: VULNERABLE (only 33 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: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
A false sense of security is worse than no security at all, see --disclaimer Sehe ich es richtig, daß der Patch erst mal von AMD bereitgestellt werden muß, bevor er Eingang in einen neuen Kernel findet?
|
norbit
Anmeldungsdatum: 9. Februar 2009
Beiträge: 255
|
Was zu AMD Patches weiß ist, das der Patch deaktiviert ist da AMD CPUs ab Werk Variante 1 nicht zulassen. Das müsste vom User freigeschaltet werden. Probleme soll es mit älteren Athlon CPUs geben bei denen die Schnittellenänderung Microcode/Kernel nicht funktioniert. Ansonsten ist man bis auf das Restrisiko von nahezu Null sicher. Wäre auch eine Sache gewesen wenn sie z. B. Ryzen auf den Markt gebracht hätten ohne in dichtgemacht zu haben.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
norbit schrieb: Ansonsten ist man bis auf das Restrisiko von nahezu Null sicher.
Warum schreiben die dann nicht mehr "nahezu Null", sondern in http://www.amd.com/en/corporate/speculative-execution: While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat. We have defined additional steps through a combination of processor microcode updates and OS patches that we will make available to AMD customers and partners to further mitigate the threat.
|
norbit
Anmeldungsdatum: 9. Februar 2009
Beiträge: 255
|
Im großen und ganzen bleibt es bei dem wie es am Anfang auch offengelegt wurde. Ich weiß jetzt auch ein bisschen mehr über CPUs mehr nicht. Also ich bin mit dem Thema durch.
|
V0LKER
Anmeldungsdatum: 23. Februar 2014
Beiträge: 1967
|
Reinarden schrieb: Mit dem von Fandpfand referenzierten, gut bekanntem Script, welches nichts am System verändert, sondern nur Kernel-Dateien usw. analysiert: https://github.com/speed47/spectre-meltdown-checker/blob/master/spectre-meltdown-checker.sh … sehen wir nun eben praktisch, was wir schon theoretisch wußten:
Wir Benutzer mit Intel-Prozessoren älter als fünf Jahre, also die große Mehrheit, sind wegen – bisher – fehlenden Microcode-Aktualisierungen seitens Intel :
nicht gegen #1 Spectre nicht gegen #2 Spectre nur gegen #3 Meltdown.
geschützt. Zu AMD kann ich momentan nichts sagen, da ich gerade nur Zugriff auf Intel-Rechner habe.
Liest sich bei Golem anders wo das gegen die 2 Variante von Spectre schützen soll
|
k1l
Anmeldungsdatum: 22. September 2006
Beiträge: 1253
Wohnort: Köln
|
https://twitter.com/DustinKirkland/status/953973769500086272 Hier die Ankündigung vom Verantwortlichen, wie es jetzt mit dem Spectre Teil der Sicherheitslücken weitergeht, nachdem es für den Meltdown Teil die Kernelupdates bereits gab. Die Kernel sind jetzt im proposed Repo zum Testen. Wenn dort keine Fehler auffallen sollen sie am Montag in die normalen Repos kommen.
|
SpiritOfTux
Anmeldungsdatum: 14. September 2017
Beiträge: 369
|
Ganzer Artikel:
Meltdown und Spectre: Weitere Kernelaktualisierungen https://www.pro-linux.de/news/1/25515/meltdown-und-spectre-weitere-kernelaktualisierungen.html Abhilfe unter Linux soll der als »Retpoline« getaufte Patch bringen, der laut Aussage von Google ohne Geschwindigkeitsverluste daherkommt.
Nachdem bereits vor geraumer die langzeitunterstützten Kernelversionen 4.4, 4.9 und 4.14 mit Aktualisierungen für »Meltdown« und »Spectre«
versorgt wurden, stellte der Linux-Kernelmaintainer Greg Kroah-Hartman nun Retpoline-optimierte Versionen der Kernelvarianten vor.
Linux 4.14.14 sowie die langzeitunterstützten Kernelversionen 4.9.77 und 4.4.112 bringen neben regulären Aktualisierungen auch weitere
zahlreiche Korrekturen und Verbesserungen hinsichtlich der beiden kritischen Lücken, was unter anderem zu weniger verschwendeten Ressourcen
bei der Korrektur der Fehler führen soll. Initiale Messungen bestätigen es, weshalb eine Aktualisierung für alle Nutzer, die ihren Kernel
selbst kompilieren, angeraten sei.
Alle Kernelversionen können ab sofort von der Seite des Kernels heruntergeladen werden. Aktualisierte Pakete der Distributoren – sofern
noch nicht geschehen – dürften bald folgen. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30 | $ uname -a
Linux K75VJ 4.14.14-041414-20180117-custom #1 SMP Wed Jan 17 14:24:38 CET 2018 x86_64 x86_64 x86_64 GNU/Linux
~ $ ls -la /boot
insgesamt 219400
drwxr-xr-x 6 root root 4096 Jan 17 16:11 .
drwxr-xr-x 24 root root 4096 Nov 29 18:51 ..
drwxr-xr-x 2 root root 4096 Jul 29 23:03 bios
-rw-r--r-- 1 root root 213855 Jan 10 14:56 config-4.14.13-041413-20180110-custom
-rw-r--r-- 1 root root 213911 Jan 17 14:35 config-4.14.14-041414-20180117-custom <<==========
-rw-r--r-- 1 root root 201247 Jan 10 11:54 config-4.9.76-040976-20180110-custom
-rw-r--r-- 1 root root 201303 Jan 17 12:32 config-4.9.77-040977-20180117-custom <<==========
drwx------ 3 root root 4096 Jan 1 1970 efi
drwxr-xr-x 6 root root 4096 Jan 17 16:01 grub
-rw-r--r-- 1 root root 48331533 Jan 15 19:30 initrd.img-4.14.13-041413-20180110-custom
-rw-r--r-- 1 root root 48327635 Jan 17 16:11 initrd.img-4.14.14-041414-20180117-custom <<==========
-rw-r--r-- 1 root root 40397461 Jan 10 13:24 initrd.img-4.9.76-040976-20180110-custom
-rw-r--r-- 1 root root 40394610 Jan 17 13:20 initrd.img-4.9.77-040977-20180117-custom <<==========
drwxr-xr-x 2 root root 4096 Jul 29 18:49 iso
-rw-r--r-- 1 root root 182704 Jan 28 2016 memtest86+.bin
-rw-r--r-- 1 root root 184380 Jan 28 2016 memtest86+.elf
-rw-r--r-- 1 root root 184840 Jan 28 2016 memtest86+_multiboot.bin
-rw-r--r-- 1 root root 3848797 Jan 10 14:56 System.map-4.14.13-041413-20180110-custom
-rw-r--r-- 1 root root 3851780 Jan 17 14:35 System.map-4.14.14-041414-20180117-custom <<==========
-rw-r--r-- 1 root root 3642929 Jan 10 11:54 System.map-4.9.76-040976-20180110-custom
-rw-r--r-- 1 root root 3645948 Jan 17 12:32 System.map-4.9.77-040977-20180117-custom <<==========
-rw-r--r-- 1 root root 8123872 Jan 10 14:56 vmlinuz-4.14.13-041413-20180110-custom
-rw-r--r-- 1 root root 8127904 Jan 17 14:35 vmlinuz-4.14.14-041414-20180117-custom <<==========
-rw-r--r-- 1 root root 7259008 Jan 10 11:54 vmlinuz-4.9.76-040976-20180110-custom
-rw-r--r-- 1 root root 7260384 Jan 17 12:32 vmlinuz-4.9.77-040977-20180117-custom <<==========
|
|