• [gelöscht]

  • Beitrag Nr. 1
Hallo,

die Sicherheitslücke ist ja wohl einigen lange bekannt, jetzt ist diese öffentlich, daher meine Frage macht arch da etwas oder ist das kernel's Sache den Intel wird da nichts machen nur schreiben kauft doch unsere neuste CPU da ist garantiert alles kaputt.

Als privater Rechner würde ich da nichts machen wollen aber als Cloud-Server?

Gruß
es wird an Kernel Patches gearbeitet, bzw. sollten diese nach meinem Wissen bereits in 4.14.11 eingeflossen sein.
Wenn ich meiner Twitter Bubble glauben schenken darf sind Spectre und Meltdown gefixed im aktuellen Arch Kernel...

  • [gelöscht]

  • Beitrag Nr. 4
Danke für die Info.
Falls 
zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
die Ausgabe 
CONFIG_PAGE_TABLE_ISOLATION=y
ausgibt, ist der Kernel gepatcht (ist der Fall bei 4.14.11).

Falls 
dmesg | grep isolation
die Ausgabe 
[    0.000000] Kernel/User page tables isolation: enabled
ausgibt, ist die Isolation aktiv. Man kann sie nämlich auch deaktivieren.
sekret schriebFalls 
zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
die Ausgabe 
CONFIG_PAGE_TABLE_ISOLATION=y
ausgibt, ist der Kernel gepatcht (ist der Fall bei 4.14.11).

Falls 
dmesg | grep isolation
die Ausgabe 
[    0.000000] Kernel/User page tables isolation: enabled
ausgibt, ist die Isolation aktiv. Man kann sie nämlich auch deaktivieren.
Ich bin momentan auf linux-ryzen-git und somit 4.15.0rc6.
Da ist bei mir von isolation in dmesg nichts zu finden, obwohl CONFIG_PAGE_TABLE_ISOLATION=y gesetzt ist. Auch der Kernelparamter pti=1 brachte keinen Unterschied.

EDIT: ok, Kernelparameter pti=on, ist richtig. Allerdings ist dieser bei mir auch bei 4.14.11 nötig.
Kabbone schrieb EDIT: ok, Kernelparameter pti=on, ist richtig. Allerdings ist dieser bei mir auch bei 4.14.11 nötig.
Interessant! Ich hab überhaupt nichts gemacht, trotzdem ist pti bei mir aktiviert. Kann das von der CPU abhängen? Ich hab 
# grep "model name" /proc/cpuinfo
model name      : Intel(R) Core(TM)2 Duo CPU     T5870  @ 2.00GHz
model name      : Intel(R) Core(TM)2 Duo CPU     T5870  @ 2.00GHz
ne (alte) Intel-CPU.

Edit, gerade entdeckt: 
# grep "bugs" /proc/cpuinfo
bugs            : cpu_insecure
bugs            : cpu_insecure
Eventuell ist das ausschlaggebend, ob pti=on nötig ist oder nicht? Bzw falls dieses Kommando keine Ausgabe zeigt, ist man dann eh sicher?
Ich hatte ganz vergessen, dass AMD in den patch irgendwo eine Abfrage auf den Vendor hinterlegt hatte, bin mir jetzt aber nicht sicher für welchen Teil der Bugs das verantwortlich war.
Aber an deiner Vermutung könnte auch was dran sein: 
#grep "model name" /proc/cpuinfo
model name	: AMD Ryzen 7 1700 Eight-Core Processor

#grep "bugs" /proc/cpuinfo
bugs		: sysret_ss_attrs null_seg

  • [gelöscht]

  • Beitrag Nr. 11
Und der 4.9 soll auch den Patch haben oder bekommen.
habe hier den Kernel laufen:
Linux linux-pc03 4.9.73-1-lts #1 SMP Fri Dec 29 19:25:27 CET 2017 x86_64 GNU/Linux
aber es gab keine Ausgaben wegen Bugs etc.

da muss ich wohl noch warten

LG SUSEDJAlex
7 Tage später

  • [gelöscht]

  • Beitrag Nr. 13
Hallo,

muss ich das Paket intel-ucode installieren um mich gegen Meltdown und Spectre sicherer zu fühlen oder reicht es
wenn ich den neusten Kernel unter Arch habe? Der Kernel soll ja das Sicherheitspatch beinhalten.

Ich habe einen Intel i5-2500K, also schon etwas älter, aus dem jahr 2011.
Kann ich dir leider nicht beantworten. Ich würde microcode aber immer einspielen, korrigiert ja auch ggf. weitere Fehler.

Soweit mir bekannt ist werden von Intel über microcode derzeit aber nur CPU‘s ab Baujahr 2013 und gepatcht. Und heute habe ich irgendwo gelesen, dass Intel das aktuelle microcode-Update zurückgezogen hat, da es wohl in einigen Fällen zu unvorhergesehenem Reboot gekommen ist.

Ich hab‘s eben trotzdem eingespielt, kann ja ggf. wieder downgraden. Meine CPU: Core i7-4702MQ.
dmesg | grep microcode

[    0.000000] microcode: microcode updated early to revision 0x23, date = 2017-11-20
[    0.980921] microcode: sig=0x306c3, pf=0x10, revision=0x23
[    0.981260] microcode: Microcode Update Driver: v2.2.
Jetzt rödelt die CPU allerdings zwischen 13-14% Auslastung im Leerlauf und laufendem Lüfter rum.

  • [gelöscht]

  • Beitrag Nr. 15
Die KPTI Kernel Patches senken nur das Risiko für Meltdown Angriffe.
Die Microcode Updates sollen mittelfristig gegen Spectre v1 und V2 helfen.

  • [gelöscht]

  • Beitrag Nr. 16
Hallo,

ich habe das Paket intel-ucode nicht installiert, aber ein dmesg | grep microcode liefert:

[    0.573308] microcode: sig=0x206a7, pf=0x2, revision=0x28
[    0.573412] microcode: Microcode Update Driver: v2.2.
Was blicke ich nicht?
Baldr schrieb... Jetzt rödelt die CPU allerdings zwischen 13-14% Auslastung im Leerlauf und laufendem Lüfter rum.
Ich kann berichten das die CPU-Last nicht am microcode-update lag. War ein anderer Prozess.
Unwissender schriebHallo,

ich habe das Paket intel-ucode nicht installiert, aber ein dmesg | grep microcode liefert:

[    0.573308] microcode: sig=0x206a7, pf=0x2, revision=0x28
[    0.573412] microcode: Microcode Update Driver: v2.2.
Was blicke ich nicht?
Hm. Ich HABE das Paket installiert (und es sollte geladen werden) und bekomme ziemlich exakt die gleiche Ausgabe. Mein Schluss daraus ist, es wird NICHT geladen bzw. hat keinen Effekt. Dem muss ich bei Gelegenheit nachgehen - jetzt erst recht.

@Unwissender: laut Wiki bedeutet Deine Ausgabe, dass keine Mickocode geladen wurde - so verstehe ich das.

Ciao
Photor
5 Tage später
Ein Update des Kernels 4.9.77-lts hat diese Sicherheitslücke geschlossen...
dmesg | grep iso
[    0.000000] Kernel/User page tables isolation: enabled

dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x28, date = 2017-11-17
[    0.656602] microcode: sig=0x306d4, pf=0x40, revision=0x28
[    0.656745] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
CONFIG_PAGE_TABLE_ISOLATION=y

grep "bugs" /proc/cpuinfo 
bugs		: cpu_meltdown spectre_v1 spectre_v2
bugs		: cpu_meltdown spectre_v1 spectre_v2
bugs		: cpu_meltdown spectre_v1 spectre_v2
bugs		: cpu_meltdown spectre_v1 spectre_v2
LG SUSEDJAlex