Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Her mit euerem Fazit zu Meltdown und Spectre
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum
View previous topic :: View next topic  
Author Message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2245
Location: Bardowick, Germany

PostPosted: Thu Feb 08, 2018 4:34 pm    Post subject: Reply with quote

franzf wrote:
Yamakuzure wrote:
Eine solche Änderung gab es bislang nicht wieder. Du kannst gcc-6.x und gcc-7.x nach Lust und Laune mischen. (Habe ich schon vorwärts und rückwärts gemacht, wenn auch nicht ganz freiwillig, und mein Laptop ist nicht explodiert. ;-) )
Danke für deinen Kommentar. Aber gerade wurde das hier gemeldet:
https://bugs.gentoo.org/646946
Ich hoffe es ist am Ende ein Konfigurationsproblem oder ein bug im nouveau-ebuild. Ich werde das auf jeden Fall beobachten.
Dazu fallen mir zwei Dinge ein:
  1. nouveau neu bauen, was eine Sache von unter einer Minute wäre, hätte das sicher schon gelöst.
  2. Ich schrieb ja: "bislang". ;-)
Spaß beiseite, das sieht mir wirklich nach einem Bug aus.

ChrisJumper wrote:
(...)***Genau genommen hatte ich mit eix eine Liste aller installierter Pakete erstellt..

Code:
# eix -Ic > list_all_packages_now.txt
# cat list_all_packages_now.txt | grep -v 02.2018 | grep -v 31.01.2018 | awk '{print $2}' > packeges_to_merge.txt


....die dann mit grep gefiltert.
Vielleicht wäre "eix-after -b sys-devel/gcc" einfacher gewesen...

Letztendlich hat man ja aber immer das Problem, dass man dann auch viele Pakete neu baut, die den gcc gar nicht verwenden. Finde ich immer blöd, aber mir ist noch keine schlaue Methode eingefallen, solche Pakete automatisch rausfiltern zu lassen... :?
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Thu Feb 08, 2018 7:35 pm    Post subject: Reply with quote

Oh eix-after kannte ich noch gar nicht, danke für den Hinweis. Im Nachhinein klingt das logisch. Ich dachte aber auch eher daran das die neuen Compiler, da sie ja vielleicht Assemblercode mit einem Zusatz versehen, eher wirken wie eine Compiler-Optimierung und deswegen alles neu bauen müssen.

Deswegen verwunderte es mich das es reicht den Kernel mit gcc 7.x zu bauen. Aber es scheint als sei das ein erster Hotfix und die neuen Compiler-Flags/Optimierungen kommen wohl erst später.

Es ist wie schon vermutet eher eine Langzeit-Entwicklung.

Aber mal eine ganz andere frage: Wenn ich einen Treiber habe der als Quellcode vor liegt, muss ich den dann mit dem selben Compiler bauen wie den Kernel oder?

Muss gleich mal schauen ob das bei meiner Fernsehkarte klappt. Die Proprietären Realtec-Sourcen konnten jedenfalls nicht mit gcc-7.3 gebaut werden, worauf hin ich die einfach runter werfen konnte und den Treiber im Kernel aktivierte. Der für diese eine Karte, zum Glück, funktionierte!

Wen hier jemand so mutig war und hat mit 6.4 einen Kernelmodul gebaut zu den richtigen Kernelsourcen.., welcher aber in 7.3 gebaut wurde schreibt doch mal eure Erfahrungen ob das Modul trotzdem geladen wurde oder ob es zu einer Kernelpanik kam. ;)

Vielleicht probiere ich das ja gleich mal aus wenn die DVB-Karte mit 7.3 nicht will...
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6240

PostPosted: Fri Feb 09, 2018 11:26 am    Post subject: Reply with quote

ChrisJumper wrote:
Deswegen verwunderte es mich das es reicht den Kernel mit gcc 7.x zu bauen.

Das reicht für meltdown. Für spectre nicht: Im Userspace musst Du schon selbst alles mit den richtigen Flags neubauen
Quote:
Aber es scheint als sei das ein erster Hotfix und die neuen Compiler-Flags/Optimierungen kommen wohl erst später.

???
Die Flags gibt es in gcc-7.3:
Code:
-fno-plt -mindirect-branch=thunk -mfunction-return=thunk
sind meiner bisherigen Kenntnis nach die richtigen Flags für Userspace.
Quote:
Wenn ich einen Treiber habe der als Quellcode vor liegt, muss ich den dann mit dem selben Compiler bauen wie den Kernel oder?

I.A. nicht. Aber im speziellen Fall wäre es unklug, einen gcc zu nehmen, der die entsprechenden Optionen nicht hat, weil Du Dir mit dem Treiber dann wieder Sicherheitslöcher in den Kernel schießt. Mölglicherweise läuft der Build auch gar nicht durch, weil die Optionen ggf. automatisch dazugefügt werden.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Sun Feb 11, 2018 6:43 pm    Post subject: Reply with quote

Hi mv!

Ja ich bin immer einen Schritt zu langsam gewesen. Gleichzeitig sind die Schritte aber noch nicht wirklich als stabil einzustufen. Daher warte ich diesmal noch einen Schritt ab bevor ich mit den Flags mein ganzes System neu baue.

Von den neuen Kernel die jetzt Spectre V1 Schutz haben wusste ich zu dem Zeitpunkt auch noch nichts. Hab jetzt aber auf allen Systemen, auch den Servern Kernel 4.15.2 im Einsatz gebaut mit gcc 7.3. Auch wenn andere hier bisher von einem Bug berichteten, hab ich nur ein Systeme mit 7.3 (aber ohne -fno-plt -mindirect-branch=thunk -mfunction-return=thunk) neu gebaut.

Rolle die Desktops aktuell noch Schrittweise aus und möchte erst mal testen ob ich da Einschränkungen hab.

Hier noch mal zusammen gefasst die Kernel-Settings..
Code:
Für Retpoline: (Ab Kernel 4.15.0, 4.9.79?) (Spectre v2)
Processor type and features: -> Avoid speculative indirect branches in Kernel

Zusätzlich den Kernel und die Module selber mit größer oder glich gcc 7.2 bauen.

Code:
Für Page Table Isolation: (Ab Kernel 4.14.11, 4.9.77?) (Meltdown)
Security Options: -> Remove the kernel mapping in user mode


Code:
Für __user pointer sanitization: (Ab Kernel 4.15.2, 4.14.18?) (Spectre v1)
Security Options: -> Harden memory copies between Kernel and userspace
                          -> Harden common str/mem functions against buffer overflows


Code:
cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTI
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline


Last edited by ChrisJumper on Mon Feb 12, 2018 9:22 am; edited 1 time in total
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6240

PostPosted: Sun Feb 11, 2018 8:33 pm    Post subject: Reply with quote

ChrisJumper wrote:
Code:
                          -> Harden common str/mem functions against buffer overflows
                          -> Force all usermod helper calls through a single binary

Diese beiden Schalter haben m.W. nichts mit spectre/meltdown zu tun.
Den ersten (Harden common...) zu aktivieren, kann nicht schaden, wenngleich er auf gentoo vermutlich ohnehin aktiv ist: Er aktiviert nur -DFORTIFY_SOURCE=2.
Den zweiten (Force all...) verstehe ich nicht, denn dann muss alles über ein Binary laufen, das bei mir nicht existiert. Und vermutllich müssen dann auch einige Dinge (udev usw.) entsprechend angepasst werden.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Mon Feb 12, 2018 9:21 am    Post subject: Reply with quote

Stimmt den Usermode-Helper braucht man nicht. Das Binary existiert bei mir auch nicht und ist wohl eher ein Hook für externe Programme. Auch schon seit einigen Jahren im Kernel, hab es einfach mal gesetzt weil ich nirgendwo eine Information fand welche Erweiterung jetzt für Spectre v1 zuständig war.

Das ist schon klasse wenn man bestimmt 20 IT-News-Seiten findet die zwar darüber berichten aber keine einzige geht mal ins Detail oder beschreibt die Settings. Welche halt auch nicht als neue Voreinstellung mit dem Kernel kommen .. danke für den Hinweis ich nehme das mal aus der Zusammenfassung raus.
Back to top
View user's profile Send private message
forrestfunk81
Guru
Guru


Joined: 07 Feb 2006
Posts: 466
Location: münchen.de

PostPosted: Fri May 04, 2018 2:16 pm    Post subject: Reply with quote

Es scheint wohl weiter zu gehen mit den Prozessor Bugs: https://heise.de/-4039302
_________________
# cd /pub/
# more beer
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1521
Location: Schweiz

PostPosted: Fri May 04, 2018 4:29 pm    Post subject: Reply with quote

So langsam habe ich das Gefühl das der x86 nicht mehr aus diesem Sumpf heraus kommt und das haben wir wohl mehrheitlich Intel zu verdanken. Da kann man nur noch auf den RISC-V hoffen...
_________________
GPG: 3FC78AEE51E5FB95
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2245
Location: Bardowick, Germany

PostPosted: Mon May 07, 2018 11:15 am    Post subject: Reply with quote

forrestfunk81 wrote:
Es scheint wohl weiter zu gehen mit den Prozessor Bugs: https://heise.de/-4039302
Hmmm... Also wenn ich sowas lese wie: "Das belegen Informationen, die c't exklusiv vorliegen." (Warum darf das denn sonst niemand wissen/veröffentlichen?) und sehe, dass Heise zur Demonstration eine Kernexplosion auf eine CPU malen musste um das Thema zu "bekräftigen", werde ich stutzig.

Netterweise gibt es ja einen Link (aber sonst keine relevanten Informationen!) zu den Sicherheitslücken. Oh, moment! Auch dort gibt es nichts, was auch nur im entferntesten weitere Hinweise liefert. Also Berichterstattung auf BILD-Niveau?

Also schauen wir mal bei Hacker News vorbei.
...hmm... auch keine Details ... Aber wenigstens ein Link auf einen Bericht, dass AMD auch Fehler hat. Immerhin. Sind die Intel-Leute also nicht ganz allein die Pöhsen.

Ich bin mal gespannt ob da noch was ernsthaftes kommt. Bislang sollen die erwähnten CVE-Nummern ja nur Blindreservierungen sein, und noch keinen Inhalt haben.

Nach Meltdown/Spectre ging die Welt auch nicht unter...
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Wed May 09, 2018 7:43 pm    Post subject: Reply with quote

Also ich bin mir nicht sicher ob es die Lücke ist die Heise so angegeben hat:

CVE 2018-8897 Betriebssystem Kernel können Speichergeheimnisse verraten
golem.de wrote:
Im Linux-Kernel sind die Versionen 4.15.14, 4.14.31, 4.9.91 und 4.4.125 gepatcht, außerdem einige Versionen von 4.1, 3,16 und 3.2


Ist wahrscheinlich ähnlich, aber sieht eher danach aus als würde der User nicht root, aber könnte Speicher auslesen.. was so ein kleiner Schritt in die Richtung ist, aber bedroht fühle ich mich dadurch nicht. Werde wohl morgen das Update machen.

Edit: War natürlich auch nicht der "Spectre-NG", sondern eine andere Lücke die eine Fehlinterpretation der CPU-Befehlssatz-Dokumentation betraf. Bezüglich Spectre-NG ist es aber richtig still geworden und es gibt wirklich keine weiteren Quellen. Zunehmend bekommt man das Gefühl das entweder die Presse es wirklich aufbauscht oder alles Substanzlos wird. Wahrscheinlich nur ein Gefühl denn im Grunde war es im Rahmen einer verantwortungsvollen Veröffentlichung ja schon immer so das Zeit gegeben wird bis der Patch fertig ist. Was ja auch der Grund war warum Meltdown und Spectre damals mit 8 Monaten Verspätung veröffentlicht wurden. Hier ist wohl eine Info Vorab an die Presse durchgesickert.

yamakuzure wrote:
Nach Meltdown/Spectre ging die Welt auch nicht unter...

Ich glaube einfach das die Zeit der Massen-Malware vorbei ist, im Grunde waren es auch damals immer nur wenige junge naive Menschen die solche Dinge los getreten haben. Heute rückt an die Stelle Gier nach Geld oder ein Säbel rasseln der Cybersoldaten. Wenn selektiv vereinzelt Probleme in unterschiedlichen Varianten auftreten bleibt das Problem länger geschützt, die Rechner anfälliger und das ist nun mal besser für alle großen Beteiligten. Die Schattenindustrie welche Krypto-Trojaner oder Schlangenöl verkaufen will, können keinen Wannacry Effekt brauchen. Sehr schön sieht man das auch bei den Smartphones. Die sind löchrig wie ein Käse aber da findet das in der Regel so nicht statt. Vielleicht Minen die einfach heimlich Kryptowährung... aber das Ausbleiben eines Medienwirksamen Effektes in der Öffentlichkeit wird wohl Standard werden.
Back to top
View user's profile Send private message
LuxJux
Apprentice
Apprentice


Joined: 01 Mar 2016
Posts: 291

PostPosted: Thu May 17, 2018 9:26 pm    Post subject: Reply with quote

Bitte entschuldigt meine Anfänger-Frage

Angenommen, ich hätte mir Spectre/Meltdown oder sonstige Malware eingefangen. Irgendwo muß sich das ja auch speichern.
Beim bootvorgang bin ich ja weder root noch user . Sicherlich, irgendwie hängt das mit dem Kernel gespeichert zusammen.
Und nun weis ich nicht, was ich fragen möchte.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Thu May 17, 2018 10:35 pm    Post subject: Reply with quote

LuxJux wrote:
Bitte entschuldigt meine Anfänger-Frage

Angenommen, ich hätte mir Spectre/Meltdown oder sonstige Malware eingefangen. Irgendwo muß sich das ja auch speichern.
Beim bootvorgang bin ich ja weder root noch user . Sicherlich, irgendwie hängt das mit dem Kernel gespeichert zusammen.
Und nun weis ich nicht, was ich fragen möchte.


Ah LuxJux ich wollte dich nicht verunsicher. Ich trage viel zu oft den Aluhut, quasi als Hobby. Generell ist es relativ unwahrscheinlich das du dir mit Linux, besonders mit einem Nieschen-Linux so was einfängst.
Weil die Rechner-Konfiguration unter Gentoo zum Beispiel sehr spezifisch ist/sein kann. Jemand der es auf deine Server abgesehen hätte müsste das schon ganz gezielt angreifen. Wenn dann jemand den Aufwand betreibt dann wahrscheinlich über Update-Mechanismen oder ganz trivial und typisch über Lücken in veralteter Software.

Spectre oder Meltdown sind jetzt in erster Linie keine Lücken die dir direkt erlauben Code Remote auszuführen. Es sind Lücken über die Programme unter ganz bestimmten Umständen von Nachbarprogramme den Speicher lesen können ungeachtet ob die mit Root oder als User laufen. Schreiben können sie nicht, also ganz so leicht kann man da das System nicht aus hebeln. Daher betrifft es eher Server oder Cloud-Dienste - halt Systeme die dauerhaft Online sind.

Wenn bei dir auf dem System Nutzer keine Shell haben.. bist du da auch schon mal nicht die Zielgruppe. Denke mal einfach an Root-Server, die halt keine physischen Rechner sind sondern wo sich 10 oder 20 Kunden eine "Dockerinstanz" teilen.. oder an andere Software as a Service Dienste...
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1521
Location: Schweiz

PostPosted: Fri May 18, 2018 5:28 am    Post subject: Reply with quote

Anbieter von Rootserver sind sicher die am schwersten betroffenen aber auch lokal ist es nicht ganz trivial. Sandboxen und Zugriffsrechte können, zumindest lesend, umgangen werden.

Beispiel:
Auf jedem Android/iOS wird der Zugriff der installierten Apps normalerweise auf das nötigste eingeschränkt und genau das ist mit den Spectre-Lücken massiv gefährdet.
_________________
GPG: 3FC78AEE51E5FB95
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Sat May 19, 2018 8:22 pm    Post subject: Reply with quote

Update:

Das von Heise bezeichnete Syslog-NG sind wohl acht weitere Lücken.
Auch wenn ich wegen der Berichterstattung am liebsten nicht auf Heise verlinken würde gibt es wegen dem eingeräumten Patch-Zeitraum von Google Project Zero wohl kein CVE Nummer oder Informationen ob Linux da jetzt auch ein Update erhält oder ob es nur Microcode-Patches von Intel sind.

https://www.heise.de/security/meldung/Spectre-NG-Intel-verschiebt-die-ersten-Patches-koordinierte-Veroeffentlichung-aufgeschoben-4043790.html

https://www.heise.de/ct/artikel/Super-GAU-fuer-Intel-Weitere-Spectre-Luecken-im-Anflug-4039134.html

Eigentlich sollte die Lücke am 7 Mai 2018 veröffentlicht werden aber Intel hat wohl um eine Verlängerung ersucht, damit sie mehr Zeit zum Patchen haben. Das kommt jetzt erst am 21 Mai also Pfingstmontag. Das ist aber nur der erste Schritt, ein weiterer soll im erst August 2018 kommen.

Einfach mal schauen ob da auch ein neuer Linux-Kernel kommt oder nur Microcode Updates oder ähnliches.

Ich finde diese Art und Weise der Veröffentlichung leider schon fast verantwortungslos. Teilweise auch die Panik-Mache von Heise die scheinbar nur Klicks bekommen wollen und wenig Informationen liefern.

Mir fällt es aktuell recht schwer die Milderungs-Ansätze und die bisherigen Lücken von den neuen zu trennen. Wenigstens mit einer CVE Nummer hätte man sie versehen können oder indem man direkt von Spectre V3 bis V10 spricht.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Wed May 23, 2018 1:17 pm    Post subject: Reply with quote

So die neuen Kernel sind da, es wird geraten auf 4.16.11 oder 4.14.43 oder 4.9.102 updaten.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b78ce4a34b761c7fe13520de822984019ff1a8f

Infos zu den normalen Nvidia-Treibern:
https://devtalk.nvidia.com/default/topic/1030082/linux/kernel-4-16-rc1-breaks-latest-drivers-unknown-symbol-swiotlb_map_sg_attrs-/1

Bei mir waren die Nvidia-Treiber dafür natürlich noch nicht angepasst. Der Legacy Treiber 340.102 lies sich compilieren aber zuerst nicht vom Kernel laden. Damit das funktioniert musste ich den Kernel neu bauen und Whitelisting aktivieren.
Code:

Security Options -->
[*] Harden memory copies between kernel and userspace
[*]     Allow usercopy whitelist violations to fallback to object size


Edit:
Code:
 cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Vulnerable

Es reicht nicht nur den Kernel zu aktualisieren, sondern man braucht auch noch das Microcode-Update von Intel. Das ist aber soweit ich es sehen kann noch nicht in Portage aktualisiert.

Edit2: Der Aktuelle Microcode ist noch nicht stable, weil er einen anderen Loader braucht als zuvor, der erst seit>=4.14.34 im Kernel ist. Andernfalls kann es zu unerwartetem Systemverhalten führen. Informationen wie man den Microcode unter Gentoo aktuallisiert finden sich Gentoo Wiki - Intel Microcode es gibt auch noch ein Wiki Seite zu Microcode im allgemeinen, aber der hat mich mehr verwirrt, da lediglich in der Fußnote auf den Intel_microcode Howtow verwiesen wurde.

Edit3 Update 20180527:
Mein anderes System ich auch nicht geschützt, eine i5 und eine i3 CPU. Es liegt wohl wie es ein Phoronix-Autor so treffend formuliert hat:

Quote:
But for Intel users today if booting to a patched kernel you will find your system reporting it's still vulnerable to Spectre V4 and even with the spec_store_bypass_disable kernel option cannot be forced enabled: you first need an upgraded BIOS / CPU microcode. Intel is working on getting that out to motherboard vendors/partners for hitting end-users in the weeks ahead. I was hoping to get access to updates today, but unfortunately as of writing that didn't pan out yet so I don't have any Intel testing to share at this point.


Zu Deutsch: "Aber wenn Intel Nutzer heute ihren gepatchten Kernel booten, wird sie ihr System benachrichtigen das es anfällig für Spectre V4 ist, selbst mit dem Kernelparameter spec_store_bypass_disable lässt sich das System nicht zwingen die Optimierung store_bypass abzuschalten. Sie brauchen zuerst ein upgrade von BIOS / CPU Microcode. Intel arbeitete in den vergangenen Woche daran die Updates über Mainboard Anbieter/Partner an die Endnutzer zu bringen. Ich hoffte das heute die Updates eintreffen, doch leider war das zum Zeitpunkt als der Artikel verfasst wurde noch nicht verfügbar. Ich habe jetzt aber kein Intel-Hardware zum Testen da."

Einfach daran das Intel noch keine Updates zur Verfügung stellt. Es sollte doch keinen Unterschied machen ob das Mainboard/Bios ein Microcode Update bekommt oder ob dies per von Linux beim Booten geladen wird?
Back to top
View user's profile Send private message
Tyrus
Tux's lil' helper
Tux's lil' helper


Joined: 03 Feb 2018
Posts: 116

PostPosted: Thu Jun 21, 2018 11:07 pm    Post subject: Reply with quote

Ich hab jetzt mal einen Test gemacht mit dem stabilen Microcode von Intel im Gentoo-Tree. Mit gcc-7.3.0 geht jetzt auch full retpoline compilation.

Code:

Spectre and Meltdown mitigation detection tool v0.37+

Checking for vulnerabilities on current system
Kernel is Linux 4.16.17-gentoo-luthien #1 SMP Thu Jun 21 23:52:04 CEST 2018 x86_64
CPU is Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES
    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  NO
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO
  * CPU microcode is known to cause stability problems:  NO  (model 0x5e family 0x6 stepping 0x3 ucode 0xc2 cpuid 0x506e3)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to Variant 1:  YES
  * Vulnerable to Variant 2:  YES
  * Vulnerable to Variant 3:  YES
  * Vulnerable to Variant 3a:  YES
  * Vulnerable to Variant 4:  YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec (x86):  YES  (1 occurrence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO
* Kernel has mask_nospec64 (arm):  NO
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  YES  (Mitigation: Full generic retpoline, IBPB, IBRS_FW)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES
    * IBRS enabled and active:  YES  (for kernel and firmware code)
  * Kernel is compiled with IBPB support:  YES
    * IBPB enabled and active:  YES
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO
  * Kernel compiled with retpoline option:  YES
    * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
  * Kernel supports RSB filling:  YES
> STATUS:  NOT VULNERABLE  (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI):  YES
  * PTI enabled and active:  YES
  * Reduced performance impact of PTI:  YES  (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* Running as a Xen PV DomU:  NO
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability:  NO
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Kernel supports speculation store bypass:  YES  (found in /proc/self/status)
> STATUS:  VULNERABLE  (Your CPU doesn't support SSBD)

> How to fix: Your kernel is recent enough to use the CPU microcode features for mitigation, but your CPU microcode doesn't actually provide the necessary features for the kernel to use. The microcode of your CPU hence needs to be upgraded. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section).

A false sense of security is worse than no security at all, see --disclaimer


Also Variante 3a und 4 sind noch offen. Allerdings hab ich im Tree gesehen gibts auch noch neuen Microcode. Teste morgen mal damit.
Back to top
View user's profile Send private message
Tyrus
Tux's lil' helper
Tux's lil' helper


Joined: 03 Feb 2018
Posts: 116

PostPosted: Fri Jun 22, 2018 7:21 am    Post subject: Reply with quote

Cooooool - jetzt bekomme ich auch Schutz gegen Variante 3a und 4. Der neue Microcode hilft. :)

Code:

Spectre and Meltdown mitigation detection tool v0.37+

Checking for vulnerabilities on current system
Kernel is Linux 4.16.17-gentoo-luthien #2 SMP Fri Jun 22 09:02:44 CEST 2018 x86_64
CPU is Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES
    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  YES  (Intel SSBD)
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO
  * CPU microcode is known to cause stability problems:  NO  (model 0x5e family 0x6 stepping 0x3 ucode 0xc6 cpuid 0x506e3)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to Variant 1:  YES
  * Vulnerable to Variant 2:  YES
  * Vulnerable to Variant 3:  YES
  * Vulnerable to Variant 3a:  YES
  * Vulnerable to Variant 4:  YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec (x86):  YES  (1 occurrence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO
* Kernel has mask_nospec64 (arm):  NO
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  YES  (Mitigation: Full generic retpoline, IBPB, IBRS_FW)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES
    * IBRS enabled and active:  YES  (for kernel and firmware code)
  * Kernel is compiled with IBPB support:  YES
    * IBPB enabled and active:  YES
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO
  * Kernel compiled with retpoline option:  YES
    * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
  * Kernel supports RSB filling:  YES
> STATUS:  NOT VULNERABLE  (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI):  YES
  * PTI enabled and active:  YES
  * Reduced performance impact of PTI:  YES  (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* Running as a Xen PV DomU:  NO
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability:  YES
> STATUS:  NOT VULNERABLE  (your CPU microcode mitigates the vulnerability)

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface:  YES  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports speculation store bypass:  YES  (found in /proc/self/status)
> STATUS:  NOT VULNERABLE  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

A false sense of security is worse than no security at all, see --disclaimer


BTW - ums genauer zu schreiben - ich hab jetzt sys-firmware/intel-microcode-2018-0616 aktiv.
Meine Maschine braucht das zwar ansich gar net, aber schaut trotzdem gut aus, zu wissen das man da jetzt auch geschützt ist.
Back to top
View user's profile Send private message
mike155
l33t
l33t


Joined: 17 Sep 2010
Posts: 613
Location: Frankfurt, Germany

PostPosted: Fri Jun 22, 2018 7:57 am    Post subject: Reply with quote

Quote:
Cooooool - jetzt bekomme ich auch Schutz gegen Variante 3a und 4. Der neue Microcode hilft.

Und? Um wieviel Prozent ist der Computer jetzt langsamer geworden?
Back to top
View user's profile Send private message
Tyrus
Tux's lil' helper
Tux's lil' helper


Joined: 03 Feb 2018
Posts: 116

PostPosted: Sun Jun 24, 2018 12:07 pm    Post subject: Reply with quote

Eine Prozentzahl kann ich dir net geben. So genau intressiert mich das persönlich auch gar nicht. Eine spürbare Performanceinbusse konnte ich bisher nirgendwo feststellen. Hab vorhin zum Beispiel qtwebengine wegen einem neuen Useflag neugebaut, da hat sich zeitlich nichts spürbares getan. Es sind so um 3 Stunden.

Wenn du das Testergebnis genau studierst, fällt mir in dem Zusammenhang der Satz ins Auge:
* Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced)

Dabei bedeutet INVPCID=Invalidate Process-Context Identifier. Das wird wohl auch eine bedeutende Rolle dabei spielen. Ich kann mich jedenfalls nicht beklagen soweit.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Thu Jun 28, 2018 7:28 pm    Post subject: Reply with quote

https://www.heise.de/security/meldung/Spectre-Sicherheitsluecken-Browser-trotz-Patches-nicht-sicher-4094014.html

alephsecurity hat auch einen PoC für den Brwoser.

Firefox schlägt sich aktuell noch gut, aber zum Beispiel bei Chromium klappte es bei mir gleich beim ersten Durschlauf, trotz Milderungs-Patch im Linux Kernel gegen Spectre 1.

Download PoC als Zip-File. Zum Testen entpacken und Spectre.html im Browser öffnen, dann die Browserkonsole öffnen (firefox - strg + shift + j) und den PoC per klick Run-Button starten.

Webkonsole in Chromium öffnet sich via: strg + shift + i

Edit: Ich kann aktuell nicht klagen so ziemlich jedes System hat alle Patches. Bis auf spec_store_bypass bei einem 8 Jahre alten System. Werde es wohl bald mit einem Hardware-Update beheben.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Sat Aug 11, 2018 9:16 pm    Post subject: Reply with quote

Bis auf die 8 Jahre alte CPU sind alle meine Systeme gegen die Angriffe abgesichert. Danke Intel, das hätte ich bisher nicht erwartet.

Auch wenn noch nicht alle Spectre-NG Lücken bekannt sind. Wenigstens wurden keine weiteren bei der aktuellen Black Hat Konferenz enthüllt. Gleichzeitig freue ich mich schon auf einen ausführlichen Vortrag beim ccc gegen Ende des Jahres.

Ein großes Lob an alle Sysadmins und Entwickler da draußen die unsere Systeme stetig verbessern und absichern. Unterm Strich bin ich ziemlich zufrieden was den aktuellen Fortschritt betrifft.

Lediglich die Bedrohungen in der Größenordnung von Stux Net, gibt mir zu Denken. Es gibt da eine gute Reportage von Alex Gibney - Zero Days. Sehr zu empfehlen um die aktuelle Bedrohungslage von Computersystemen einzuschätzen.
Back to top
View user's profile Send private message
mike155
l33t
l33t


Joined: 17 Sep 2010
Posts: 613
Location: Frankfurt, Germany

PostPosted: Tue Aug 14, 2018 8:12 pm    Post subject: Reply with quote

Quote:
Auch wenn noch nicht alle Spectre-NG Lücken bekannt sind.

Bitte schön, hier kommen die nächsten Varianten: https://www.heise.de/security/meldung/Spectre-NG-Foreshadow-gefaehrdet-Intel-Prozessoren-4137209.html.

In dem Heise-Artikel werden 16 (!!!) Varianten aufgezählt... Ich muss gestehen, dass ich langsam den Überblick verliere... :cry:
Back to top
View user's profile Send private message
mike155
l33t
l33t


Joined: 17 Sep 2010
Posts: 613
Location: Frankfurt, Germany

PostPosted: Wed Aug 15, 2018 9:24 am    Post subject: Reply with quote

Die gute Nachricht zu den neuen Spectre-Lücken: die Kernel-Entwickler wollen morgen "Mitigation-Patches" freigeben.

Die schlechte Nachricht steht - wie üblich - im Kleingedruckten:

Quote:
Laut den derzeit kursierenden Informationen soll der Flush des L1-Cache die Performance je nach Workload um 15 bis 50 Prozent senken.

Das kann ja wohl nur ein schlechter Scherz sein!
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2245
Location: Bardowick, Germany

PostPosted: Wed Aug 15, 2018 11:16 am    Post subject: Reply with quote

mike155 wrote:
Die gute Nachricht zu den neuen Spectre-Lücken: die Kernel-Entwickler wollen morgen "Mitigation-Patches" freigeben.

Die schlechte Nachricht steht - wie üblich - im Kleingedruckten:

Quote:
Laut den derzeit kursierenden Informationen soll der Flush des L1-Cache die Performance je nach Workload um 15 bis 50 Prozent senken.

Das kann ja wohl nur ein schlechter Scherz sein!
Weiterhin heißt es: "Wer keine virtuellen Maschinen einsetzt, braucht indes keinen Geschwindigkeitsverlust fürchten."
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1521
Location: Schweiz

PostPosted: Wed Aug 15, 2018 11:24 am    Post subject: Reply with quote

Yamakuzure wrote:
mike155 wrote:
Die gute Nachricht zu den neuen Spectre-Lücken: die Kernel-Entwickler wollen morgen "Mitigation-Patches" freigeben.

Die schlechte Nachricht steht - wie üblich - im Kleingedruckten:

Quote:
Laut den derzeit kursierenden Informationen soll der Flush des L1-Cache die Performance je nach Workload um 15 bis 50 Prozent senken.

Das kann ja wohl nur ein schlechter Scherz sein!
Weiterhin heißt es: "Wer keine virtuellen Maschinen einsetzt, braucht indes keinen Geschwindigkeitsverlust fürchten."

Trotzdem ist es eigentlich eine riesen Sauerei, natürlich nicht von denen die diese Lücken fixen. Beim Kauf einer CPU bezahlt man die ganze Leistung und nach dem bugfixing bleibt einem dann effektiv nur noch eine Teilmenge davon...
_________________
GPG: 3FC78AEE51E5FB95
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum