# Her mit euerem Fazit zu Meltdown und Spectre

## ChrisJumper

Intel - Kauft ihr jetzt AMD oder macht ihr um Ryzen einen bogen?

Immerhin gab es hier berichte das bei der Installation auf AMD Ryzen einige Probleme auftraten oder sind da mittlerweile die Probleme durch Updates komplett behoben und die Installation läuft perfomant und bequem durch?

Mich ärgert aktuell nicht nur die Diskussion um Meltdown*/Spectre und die damit verbundene ca. 20% langsamere Ausführung von jeglichem Code. Sondern auch Intels Art überall diese Management Engine

Wie geht ihr damit um? Neue Hardware kaufen oder die alte mit Einbußen halt weiter verwenden?

Bei der Managment Engine bin ich mir auch immer noch nicht sicher welche Sicherheits-Probleme das hervorruft, nicht jeder Mainboard-Hersteller bietet ja einen Patch für die Problematik an und ich hoffe einfach das sich die ME nicht Remote ohne direkten Hardware Zugriff oder Bios Zugriff. Ausnutzen lässt.

Auch bleibt die Frage offen ob man das Problem mit einem Patch in den Griff bekommt. Intel hat ja angekündigt das sie alle Prozessoren nach 2012 noch mit einem Patch nach bessern wollen. Ob das die Leistungseinbußen behebt?

Gleichzeitig könnte es dann aber ein Vorteil sein das die Systeme mit der Management Engine über eine Art Betriebsystem on Chip, verfügen. Selber kommt mir dabei aber Unbehagen auf. Ich hab halt gedacht die packen alle Funktionen als in Schaltkreise gegossene Hardware und dann wäre ein Patchen nicht mehr möglich. Aber anscheinend gibt es auch eine Firmeware die dann einfach im Bios liegt und die Intel ME noch mit einem Firmewarepatch versorgt. Vielleicht kann sich da noch einiges zum besseren wenden.

Ärgerlich finde ich den Gedanken das diese Chips aber quasi ein integriertes OS mitbringen schon, denn wir wissen ja alle wie Anfällig Router oder WLAN Accesspoints oder IoT Geräte mit der Zeit werden, wenn man sie nicht patched. Aus dem selben Grund finde ich auch die Management Engine von Intel so unsexy. Es ist als hätte ein Angreifer heimlich eine Change das Bios zu hacken oder eine Art Dauer Krypto-Miner im Hintergrund laufen.

Sicher aus militärischer Sicht macht es Sinn, möglichst viele Systeme für einen DDOS Angriff im Petto zu haben, die dann in der Art eines roten Knopfes in dem neuen Kalten Krieg für Frieden im Cyberwehr-Land sorgen.

Praktisch gesehen finde ich die Idee aber überhaupt nicht gut. Ich fühle mich dadurch unsicherer und Anfälliger und das Verhältnis zu meinen Computer hat was die Wiredness Skala betrifft einen starken Ausschlag nach oben erhalten.

Es bleibt das diffuse Gefühl der Sicherheit. Ähnlich wie im Kalten Krieg wo niemand möchte das die Waffen abgeworfen werden und die Systeme möglichst sicher sein sollen, aber dauerhaft die Gefahr besteht das "Doktor Seltsam oder wie ich lernte die Bombe zu lieben." jederzeit die eigene Wirklichkeit und die Vorstellung von physikalischen Gegebenheiten aus hebelt. 

Besonders diffuse ist das Gefühl wenn man darüber nachdenkt das diese Sicherheitslücke schon seit Juli 2017 (Meltdown) bzw Juni 2017 (Spectre), bekannt ist und wir knapp 7 Monate auf den Patch warten mussten!

Da kann mir doch keiner erzählen das auf dem Exploit-Schwarzmarkt eine solche Lücke nicht schon lange gehandelt oder ausgenutzt wird. Es hat auch etwas von dem bewussten Design einer Backdoor finde ich.

Wahrscheinlich werde ich mittelfristig die Mainboards tauschen und auf Ryzon wechseln, im Zuge einer direkten Hardware-Aktualisierung.

P.s.: Frohes neues Jahr an alle Gentoo-Nutzer und Entwickler!

*Link geht hier im Forum nicht, wohl wegen der Klammern daher folgt er hier:

https://de.wikipedia.org/wiki/Meltdown_(Sicherheitsl%C3%BCcke)

https://de.wikipedia.org/wiki/Spectre_(Sicherheitsl%C3%BCcke)

----------

## forrestfunk81

Auch wenn ich sonst eher der Aluhutfraktion angehöre, glaube ich in diesem Fall nicht an Vorsatz aka. Backdoor. Ich denke von dieser Art Side Channel Angriff waren wohl alle Beteiligten überrascht. 

Neue Hardware kaufen macht vorerst keinen Sinn. Gibt ja keine (x86) die gegen Spectre auch immun ist.

Ich war von Anfang der 90er bis vor ein paar Jahren steter AMD Fan und habe mir nur entsprechende Hardware gekauft. Erst als AMD gar kein Land mehr gesehen hat und ich auch noch von Desktops auf Laptops umgestiegen bin, bin ich zu Intel gewechselt. Jetzt weiß man ja, wie sich Intel einen Teil ihres Performance Vorsprungs durch Verzicht auf Sicherheit erkauft hat. Wenn der nächste Hardware-Wechsel ansteht (vllt nächstes Jahr) und es energiesparsame aber leistungsstarke AMD Notebooks gibt, werde ich reuevoll wieder zurückwechseln.

----------

## musv

Korrigiert mich bitte, wenn ich falsch lieg: Ohne jetzt tiefer in der Materie zu stecken, sollte die Lücke doch hauptsächlich Cloud- und virtualisierte System betreffen. Falls ich das richtig verstanden hab, können wohl über das Auslesen des Lookaheadbuffers auf der CPU die Daten anderer eigentlich geschützter Speicherbereiche gelesen werden. Also kann eine VM theoretisch die Daten einer anderen VM abgreifen. Dazu muss aber eine entsprechende Anwendung auf dem betroffenen Rechner installiert sein. 

Oder mit anderen Worten ausgedrückt: Für den Privatnutzer dürfte die Lücke irrelevant sein. 

Im Serverbereich soll's wohl bei der IO-Leistung vor allem mit kleineren Dateien unter Windows ziemliche Performanceeinbrüche von bis zu 60% geben.

----------

## ChrisJumper

Edit:

heise.de: FAQ zu Meltdown und Spectre

Heise hat da ein gutes FAQ zu.

Edit-Ende.

Ja eher der Cloudbereich wegen Docker und openstac. Aber eigentlich auch alle Normale Server.

Ist ein bisschen wie Heartbleed nur das nicht direkt die Krypto bzw der Netzwerk Stack betroffen ist.

Aber Adress Layout Space Randomization ist dadurch wirkungslos geworden. Man kann einfacher Bufferoverflow Schwachstellen nutzen um sich eine Rücksprungadresse zu greifen und so quasi einen Root-Prozess oder Treiber Fehler ausnutzen den ASLR zuvor verhinderte. 

Das man alle Speicherinhalte von Adesse x bis y (Achtung Hörensagen) auslesen kann erinnert mich an die Windows 98 Zeit.

Von daher betrifft das alle Anwender auch die Privatleute. Ist halt eine Frage der Zeit bis es für Browser Surf By oder Advertise bugs gibt

Muss mich noch genauer damit befassen und vllt ist es nicht so schlimm, aber ich dachte zuerst es wäre weniger schlimm und das mit dem Adressbereich klang nicht gut. Hab da leider noch keine Zeit gehabt selber mal die Exploits zu testen oder auszuprobieren.

Aber wenn es nicht schlimm wäre würde man doch drauf verzichten und fehlendes ASLR in kauf nehmen für X Prozent mehr Leistung.

Edit: Wie im Heise-Howto Man kann halt wenn man die Browser angreift, Logindaten die in der Browser-Crypto-Wallet liegen auslesen und theoretisch auch wenn man eine Werbung oder cross-site scripting Lücken nutzt das man dann die im Speicher befindlichen Password User Kombinationen im Browser auslesen. Weil sie sich zum Beispiel in der Browser Session ja zeitgleich im RAM befinden, auch bei CLIENT Systemen, Handys, Smart-TVs...

Ist echt eklig. So eklig das die Browser Hersteller einen Meltdown/Spectre Patch in der letzten Version panisch nach gereicht haben um ein wenig Schutz zu bieten wenn das Betriebssystem noch keinen Patch hatte. Hab mir die Browser-Sache aber auch nicht angeschaut, kann sein das das nur das Crypto-Wallet ... ach mist Wie heißt das richtig? Dachte damals auch das das Wallet halt keien Kryptowährungen sondern die Zugangsdaten enthält. Genauer und besser ist aber den Key-Ring/Schlüsselbund der im Browser integriert ist und Nutzernahmen/Passwörter Kombis verwaltet.

Ist an manchen ecken schon Ekliger als eine ASLR Lücke. Wie im Beispiel des Browsers..

Damals machte man Witze das der Editor zu einem Betriebssystem wird, mittlerweile ersetzt der Browser fast das Betriebsystem. ;)

Wegen den Kernel-Patches und Performance Verlusten, gibt es z.B. ein tolles Video (oder Artikel) von Digital Foundry wie es sich bei Windows Systemen verhält und das ganze sich negativ auf Videospiele auswirkt, wegen größeren Leistungseinbußen.

Das Schlimme an der Sache ist, es ist noch nicht abzusehen ob die KAISER Patches Schutz bieten, sie verringern wieder nur die Wahrscheinlichkeit das der Angriff erfolgreich ist (wie bei ASLR auch schon). Problem ist aber das die Nachwehen der Geschichte noch viel größer sein können als erwartet. Die Hardwarelücke selber kann man auch durch Patches nicht fixen. Neue Hardware (später wenn es welche mit Fixes gibt) ist da die sicherste Methode. Die Aktuellen Kernel-Patches und Micro-Code Updates machen es Angreifern aber schwerer.

Für Offline-Anwendungen macht es aber keinen Sinn. Spielt man also keine Online-Games sondern Offline oder vielleicht nur im Vertrauten LAN, könnte man alte Kernel einsetzen. Wenn man Lokale Angreifer ausschließen kann.

Aber in unserer vernetzten Welt wird das immer schwieriger.

Edit: Ahh jetzt verstehe ich das erst, das Problem ist nicht direkt im ASLR, sondern in der Sprung-Vorhersage der Prozessoren. Quasi die Mechanik die bei den Prozessoren eine Beschleunigung erzielt weil sie versucht zu erraten wie die Sprung-Register und der im Speicher zu habende virtuelle Adressraum in "Zukunft" sein werden. Gut dann ist das kein typischer Buffer-Overflow und hoffentlich auch kein Windows-98 Szenario mit Auslesemöglichkeiten zum Speicher.

----------

## ChrisJumper

Ach das wichtigste Fazit hab ich leider vergessen es für euch DICK zu unterstreichen: Passwörter ändern!

Weil halt sowohl in Cloud oder Virtuellen Serveranwendungen die Webseiten Bereitstellen, die Passwörter abhanden gekommen sein könnten. Oder in den letzten Tagen über Angriffe auf Browser oder halt Smartphone-Browser etc..

Denn es besteht die Chance das die eigenen Passwörter es schon Listen geschafft haben die aktive Gehandelt werden.

Edit: Fuck, alle Ios Geräte sind betroffen und auch Qualcomm hat bestätigt das ihre CPUs betroffen sind. Leider gibt es da aktuell noch keine Liste welche genau betroffen sind, aber wahrscheinlich auch meine Smartphones auf denen ich LineageOS ich einsetze. Hoffentlich bekommen die älteren Kernel-Version der Android Geräte (Kernel 3.4.113) auch einen Kaiser-Patch, noch besser wäre halt zu wissen das sie keinen Brauchen und dadurch keine Performance Einbußen hätten.

----------

## misterjack

 *ChrisJumper wrote:*   

> Wie geht ihr damit um? Neue Hardware kaufen oder die alte mit Einbußen halt weiter verwenden?

 

In meinen Fall wäre ich ziemlich dämlich mit einem Wechsel in finanzieller Hinsicht. Vom i7-3520M im Thinkpad X230 über einen i5-3570T (nur 45W) im Heimserver (der mit RT-Kernel läuft, wegen latenzfreier Audioverarbeitung) bis zum i7-4790K im Arbeits/Spielerechner ist das in Summe ein vierstelliger Betrag, den ich da investiert habe. Bei normaler Benutzung kommt keiner der Systeme über Load 0.5 hinaus; wenn die mehr als üppigen Reserven jetzt ein wenig schrumpfen, werde ich das wohl nichtmal merken.

 *ChrisJumper wrote:*   

> Ach das wichtigste Fazit hab ich leider vergessen es für euch DICK zu unterstreichen: Passwörter ändern!

 

Das sollte man sowieso regelmäßig machen  :Smile: 

Edith: passender Comic  :Very Happy: 

----------

## forrestfunk81

Ausführliche Infos gibt es auch im englischen Gentoo Forum u.a. mit Links zu funktionierenden PoC zu Spectre und Meltdown.

Um etwas Licht ins Dunkel zu bringen:

Meltdown is für Server, Cloud, VMs und Co schlimmer als für den durchschnittlichen Desktop Benutzer. Mit diesem Intel Bug kann der Kernelspeicher ausgelesen werden und somit Informationen über andere VMs oder Mandanten gesammelt werden. Mit den Kernelspeicher Information kann man eventuell auch andere Angriffe vorbereiten um aus einer VM auszubrechen. Für diesen Bug gibt es einen Kernel Patch, welcher den Kernel- und Userspace- Speicherbereich deutlich trennt. Das geht allerdings zu Lasten der Performance. System Calls werden dabei deutlich langsamer. Also langsamere IO, Festplatten- und Netzwerkzugriffe. Auf Spiele etc sollte sich das weniger auswirken als auf VM-Betrieb, Datenbank und Co. Wer einen betroffenen Intel Prozessor hat sollte:

```
CONFIG_PAGE_TABLE_ISOLATION=y
```

 aktivieren. AMD User können sich das sparen und sind dann nicht von den Performance-Einbußen betroffen.

Spectre betrifft alle gängigen CPUs (AMD wohl nur in Variante 2). Mit Spectre lässt sich nicht der Kernelspeicher auslesen, aber der Userspace-Speicher. Ein bösartiges Programm kann also auf den Speicherbereich anderer Programme zugreifen und dort z.B. Passwörter auslesen. Mozilla hat in einem Blogeintrag erwähnt, dass sie das auch über Javascript im Browser ausnutzen konnten. Für diesen Angriff sind sehr genaue Zeitstempel nötig. Deshalb hat Mozilla als Quick Fix bzw. als temporäre Mitigation die Zeitstempel-Genauigkeit im Firefox verringert. Das wird wohl noch nicht der letzte Patch dazu sein. Man kann wohl Software durch Compiler Flags sicher gegen Spectre machen. Das wird auch im englischen Teil des Gentoo Forums diskutiert. Das habe ich allerdings in den letzten Tagen nicht weiter verfolgt. Außerdem erschweren die CPU Microcode Updates (siehe Wiki) der Hersteller Spectre Angriffe.

Beide Bugs (bzw. alle drei Varianten) werden ausgenutzt in dem bösartiger Code auf einer betroffenen CPU ausgeführt wird. Meine größte Sorge ist hier durch Webseiten nachgeladenes Javascript. Dafür gibt es zwar diverse Scriptblocker, aber ganz kommt man (ich) um Javascript leider nicht herum.

----------

## ChrisJumper

Danke für den Hinweis forrestfunk81,

ich hatte in der Tat nirgendwo diese Konfiguration gesetzt aber die Tage noch mal schnell alle Kernel neu gebaut.

Ich bin froh das meine Annahme über ALSR falsch war, das was Fefe in seinem Blog angesprochen hatte, lesenswert ist auch der Verweis auf Negative Result: Reading Kernel Memory From User Mode von Anders Fogh einer der Forscher an der Lücke. Das Paper ist vom 28 Juli 2017 und war bei Fefe auch verlinkt.

Es ist wohl komplizierter da die Sprungvorhersage zu manipulieren. Speicher auslesen auch Kernelspeicher auf ungepatchten Systemen ist kein Problem wenn man sehr viel Zeit bei der Ausführung hat. Das Webseiten-Szenario greift da nicht weil der Code der Webseite ja nur aktiv bleibt bis der Browser oder das Tab geschlossen wird. Aber da fällt mir dank Adware-User-Tracking direkt eine Möglichkeit ein das der Server den User und der einzelnen Devices per Fingerprint identifiziert und dann einfach eine Pause einlegt und später an anderer Stelle weitermacht. Fällt dann natürlich auch mehr auf, aber wofür gibt es Botnetze wenn nicht zum umleiten und verschleiern von Traffic?

Ausschließen kann man das Umleiten des Programmflusses wohl auch nicht, aber wenigstens ist es sehr kompliziert das zu versuchen, aber die Lücke gibt das vielleicht her. Berichten zufolge, gibt es Varianten von Meltdown/Spectre bei denen Angreifer volle Kontrolle (? vielleicht lesen und schreiben) über Angreifbare Adressen des Kernelspeichers hat (vor dem KAISER-PATCH). Aber das könnte eine Frage der Zeiteinteilung sein. Spannend wäre ob man auch in den Kernel-Speicher schreiben könnte und ob man so quasi Shell-Code wie bei einem Typischen Buffer-Overflow platziert bekommt indem man dann eine Rücksprungadresse überschreibt mit der Adresse des Shellcode.

Letzteres ist eventuell gar kein Problem weil es andere Schutzmechanismen gibt die das verhindern (Code der einen Canary verwendet, oder Speicher der als NonExecuteable markiert ist). Hängt davon ab wie die Branch Prediction arbeitet und wie Änderungen in den Arbeitsspeicher wandeln. Da muss ich noch mehr drüber Lesen.

Doch das ist wohl nicht ganz so einfach und damit ist bis auf weiteres die Lücke nicht so Brand gefährlich wie bisher von mir angenommen.

Mit mehr Entwicklungszeit und Testing könnte ich mir aber vorstellen das man je nach Architektur-Typ und Laufzeitumgebung (Smartphone, Desktop, Geldautomat, Cloudserver, NAS, Fritzbox, Smart-TV, Alexa...) ganz unterschiedliche Angriffsszenarien für eine Maschine konstruiert, die in eine Art Rainbowtable packt die dann auch auf den Geräten die Laufzeitumgebung prüft und CPU oder RAM-Auslastung und dann hätte man schnell einen fiesen Exploit gebastelt der dann auch Code zur Ausführung bringt.

Sicher das löst nicht das Problem wie der Code auf die Systeme kommt. Aber das war bei IT-Systemen ja alter Kaffee, auch das man sich zum bauen eines Exploit gezielte Gedanken machen muss und der Exploit am Ende mehr oder weniger Universell ausfällt.

Das wird uns bestimmt noch Jahre beschäftigen und ungemütlich!

Wenn man es noch nicht hat am besten sofort Gute Backups regelmäßig fahren auf Offline-Systeme.

Wenn Remote-Code Execution durch andere Lücken in eine ungemütliche Konstellation rücken könnten da Krypto-Trojaner auch für Server und Linux kommen. Aber dafür müsste man erst mal auf die Systeme drauf und mit den neuen KAISER-Patches haben sich die Chancen verbessert das der Angriff (nur mehr Zeit braucht). Im Idealfall bekommt man das halt mit das im Hintergrund was passiert. Hat man Pech, arbeitet da schon der Krypto-Trojaner und verschlüsselt fleißig.

Update: Gibt jetzt auch eine Infoseite im Gentoo-Wiki zu der Sicherheitslücke

----------

## schmidicom

Ich war noch nie ein Freund von Intel und nach dem was sie hier abgeliefert haben ist das auch nicht wirklich besser geworden.

Obwohl Intel schon länger davon wusste haben sie in ihrer Panik vor dem AMD Ryzen mit vollgas fehlerhafte Prozessoren raus gehauen. Und als ob das an sich nicht schon fragwürdig genug wäre setzt der Intel-Chef kurz vor der Veröffentlichung mit seinem kleinem Insider-Handel dem ganzen noch die Krone auf.

Dummerweise hat sich AMD dabei euch nicht gerade mit Ruhm bekleckert.

Offenbar musste man AMD jede noch so kleine Info regelrecht aus der Nase ziehen und selbst diese Ausbeute war mehr als mager. Dazu führte diese zögerliche Informationsweitergabe allem anscheinen nach auch noch dazu das Microsoft ein Microcode-Update zurückziehen musste weil dies etliche Windows-Installationen in den Bluescreen trieb.

Doch die OS-Hersteller machen es leider auch nicht besser. Apple denkt wohl sie könnten das ganze durch ignorieren einfach aussitzen und Microsoft patcht hektisch herum wodurch letztlich mehr Probleme geschaffen als gelöst werden.

Das verhalten der Gentoo Devs fand ich bis jetzt jedoch recht ordentlich: [TRACKER] kernel: Meltdown and Spectre - A flaw in modern processors (CVE-2017-{5715,5753,5754})

Der wirklich einzige große Player der hierbei nicht komplett abgekackt hat ist Google.   :Sad: 

Das hätte meiner Meinung nach deutlich besser laufen können...

----------

## Yamakuzure

 *ChrisJumper wrote:*   

> Mich ärgert aktuell nicht nur die Diskussion um Meltdown*/Spectre und die damit verbundene ca. 20% langsamere Ausführung von jeglichem Code.

 Hier muss ich mal reingrätschen.

Die ca. 20%ige langsamere Ausführung hat der Spiele-Entwickler Epic auf deren Fortnite-Backend-Servern festgestellt. Und dabei geht es um die massiven IO-Prozesse, und sicher nicht um die "Ausführung von jeglichem Code".

Normale Desktop-PCs und Laptops ab Skylake sollten so gut wie garnichts merken. Ich habe in meinem Laptop noch einen Haswell, und ich merke weder unter Linux, noch unter Windoof 10 irgendwas von den Updates (Treiber, System, Microcode.)

Benchmarks, hätte ich älter Werte zum vergleichen, würden mich wahrscheinlich eines Besseren belehren. Aber subjektiv (also "gefühlt") betrachtet ist da nichts zu merken. (Und Mass Effect 1-3 zeigen immer noch die selben FPS wie vor drei Monaten. Das habe ich mir zumindest mal spaßeshalber angeschaut.  :Wink: )

Obwohl Intel einen Bericht veröffentlicht hat, nach dem die Prozessorleistung um bis zu 10% zurückgehen kann, habe ich davon noch nichts gemerkt.

(Hinweis: Da beim Daddeln hauptsächlich die GraKa beansprucht wird, ist das aber auch nicht wirklich verwunderlich.)

Ansonsten bin ich wenig bis garnicht in Panik. Sowohl Spectre wie auch Meltdown bedürfen das Ausführen von Schadcode auf dem Zielrechner. Alles an Embedded Geräten, wie Router z.B., sind damit schonmal nicht anfällig. Solange man damit nicht surft (denn das mit dem Schadcode geht auch über JavaScript) sollten auch Smart-TVs nicht wirklich betroffen sein.

Der nächste Grund für meine Entspannung ist die unglaublich niedrige Geschwindigkeit, mit der ein Angreifer dann tatsächlich auf den Speicher eines angegriffenen Rechners zugreifen kann.

Bitte nicht falsch verstehen. Die Lücken sind da, und für Rechenfarmen und Cloud_Service-Anbieter ein echter Super-GAU. Einen Angriff auf einen Privat-PC oder Laptop muss ein Angreifer aber wirklich wirklich wollen.

----------

## Yamakuzure

Der Vollständigkeit halber und zum entpaniken: Hoffnung bezüglich Meltdown

Das ganze (Meltdown, nicht Spectre) schein harmloser zu sein, als es aussieht

----------

## ChrisJumper

Danke für den Link Yamakuzure,

hatte den Beitrag bei Fefe natürlich auch gelesen, und das was Herr Schräder im Heise-Forum auch noch kommentiert hatte. Dort hatte er auch auf eine github Seite verlinkt wo er den Versuch den Exploit nach zu bauen beschrieb. Leider fand ich unter seinem Namen und der Crypto Magic Suche nicht wirklich etwas zu seiner Person, wollte ihn schon unbedingt Kontaktieren.

Auf mich wirkt es halt so als sei es ein Problem die Sprungvorhersage des Prozessors so einzurichten das man die Hinweise auch aus dem L1 Cache lesen kann. Zudem handhaben das laut Heise oder Anders Fogh (bin mir da gerade nicht so sicher), die Prozessoren unterschiedlich.

Es war ja die Rede davon das man es messen kann ob Daten aus dem Cache geholt werden statt aus dem Speicher, weil die Adresse/Antwort in wenigen Zyklen verfügbar ist statt in über 400.

So ganz erschloss sich mir nicht ob Herr Schräder das Problem erfasst hat, oder er sich einfach nicht genug mit der Architektur moderner Mikroprozessoren auskennt. Bei Twitter scheint es jemand von Microsoft nach implementiert zu haben und konnte bestätigen das man alle Speicherbereiche auslesen konnte.

Ob das jetzt aber auch der Proof of Concept Code war, bei dem auch hier im Gentoo-Forum schon angemerkt wurde das man Root braucht damit der Code läuft. Das weiß ich nicht. Was ich bisher gelesen hatte war, das es Root sein musste damit der PoC die werte mit den Adressen im Speicher vergleichen kann, beziehungsweise Kernelcode initialisieren der dann Angegriffen wurde. So genau habe ich mir das bisher leider immer noch nicht angesehen.

Bei allem was ich bisher gelesen hab war, das der Code wie einer Race-Condition abläuft, wenn der Speicher ausgelesen wird. Demnach gibt es immer Wahrscheinlichkeiten in denen es klappt oder nicht klappt und ist nur durch mehrere Versuche reproduzierbar. Ein Erfolg lässt sich aber durch die Messungen der Antwortzeit verifizieren. Dennoch weiß man in der Regel nicht ob dann an der Adresse die man ausgelesen hat, auch die vom Angreifer erhoffte Information zu finden ist oder ob da wieder etwas anderes lag.

Letztlich ist das von der Last abhängig und der verwendeten Software. Theoretisch, sind das aber alles Punkte die man mit viel Aufwand und Tests einschränken kann. In etwa so wie die Angriffe auf Kryptografie. Deswegen bin ich skeptisch. Alle bisher genannte Gegenmaßnahmen machen es den Angreifern schwerer das sie ihr Ziel erreichen, beziehungsweise Erhöhen die Rechenzeit die der Angreifer warten muss. Ausschließen kann man die Lücke aber bisher nicht. Wobei das vielleicht sich auch nur auf Spectre 2 bezieht. Die ganze Lage ist da ein wenig unscharf. Weshalb viele sich erst mal nicht zuständig fühlten:

- "Nein mein Problem ist das nicht, das muss der Kernel machen."

- "Nein mein Problem ist das nicht das muss die Software machen!"

- "Nein mein Problem ist das nicht, das muss die Hardware machen."

Auch wenn es wahrscheinlich verschwendete Zeit ist sich mit der genauen Funktionsweise zu beschäftigen, hat es einen gewissen Unterhaltungswert, auch was die Lösungsmöglichkeiten betrifft.

----------

## schmidicom

Also ich finde die Verharmlosung aus einigen Links hier schon bedenklich, immerhin weiß kaum jemand welche seiner Programme alle eine Internetverbindung aufbauen und dadurch womöglich genau so anfällig sein könnten wie ein Webbrowser welcher ja Inhalt (z.B. Java, JavaScript, etc.) herunter lädt und auch ausführt. Wie viele Programme haben einen eingebauten mini-Webbrowser? Selbst die Hilfe per F1 ist oft nur ein Browserfenster das eine Webseite aufruft.

Meltdown und Sepctre sind auch für private Rechner keine Kleinigkeit.

Und die Performance ist auch eine Sache welche man besser nicht verharmlosen sollte. Nach dem was man so liest reagieren einige Programme kaum bis gar nicht, andere wiederum laufen bis zu 60% langsamer und/oder stürzen sogar ganz ab.

Leicht OT:

Warum hat Debian ein neueres Microcode-Update für AMD-CPU's als das GitRepo von kernel.org?

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode

http://ftp.debian.org/debian/pool/non-free/a/amd64-microcode/

----------

## Yamakuzure

 *ChrisJumper wrote:*   

> Leider fand ich unter seinem Namen und der Crypto Magic Suche nicht wirklich etwas zu seiner Person, wollte ihn schon unbedingt Kontaktieren.

 Siehe https://cryptomagic.eu/index.php/ueber-uns/impressum - Er ist der Geschäftsführer. (meltdown@cryptomagic.eu kann zum Kontakt verwendet werden)

Aber hier ist sein Xing-Profil  :Very Happy: 

Allerdings ist die Referenzliste der Firma jetzt nicht unbedingt ein dicker Wälzer. Leider sagt das nichts über die Personen dahinter aus.

 *schmidicom wrote:*   

> Also ich finde die Verharmlosung aus einigen Links hier schon bedenklich

 Von Verharmlosung kann keine Rede sein. Das Problem ist da, und nicht zu unterschätzen.

Aber die Panikmache, als würden schon 10 finstere Gestalten grinsend im Hof stehen um über dein Handy mal locker per WLAN im Smart TV deine TAN-Liste auszulesen (die in Papierform in der Schreibtischschublade steckt), finde ich etwas übertrieben. Gerne wird so getan, als wenn diese PoCs (mehr sind es nicht! Proof of Concept, also alles exakt so hergerichtet, dass es funktioniert, um zu beweisen, dass es möglich ist!) furchtbar einfach wären. Mitnichten.

 *https://meltdown-core-catcher.com/story.html wrote:*   

> Dem Google Project Zero Bericht ist, im Gegensatz zum Meltdown-Paper, zu entnehmen, dass es für Meltdown eine Abhängigkeit zum Vorliegen der Daten im Prozessor Cache gibt. Diese Abhängigkeit hat möglicherweise auch schon im Juli 2017 Anders Fogh verwirrt, so dass er in seinem Blog von Effekten des prefetch CPU-Befehls schreibt, die das Google Project Zero in ihrem Bericht nur ohne Erfolg versuchten.
> 
> Diese Rolle des Vorliegen der Daten im Prozessor Cache wäre im Bezug auf die Tragweite von Meltdown enorm: Es wäre hierdurch keinesfalls so, dass, wie das bislang angenommen wird, beliebiger Speicher ausgelesen werden kann, sondern nur der Speicher der kurz zuvor auf der gleichen CPU verarbeitet worden ist und noch während des Angriffs auf dieser im besagten Cache verfügbar ist. Dies würde dazu führen, dass das zufällige vorliegen für nicht Kernelspeicherbereiche im Cache nicht nur noch unwahrscheinlich ist, sondern dass auch das gezielte Herbeiführen des Vorliegens, wie bei den bereits funktionierenden Angriffsprogrammen, für nicht Kernelspeicheradressen nochmals schwieriger werden würde: Hierzu müsste der Kernel oder der angreifende Prozesse eine Veranlassung haben, entsprechende Speicherstellen eines unbeteiligten Prozesses über die virtuelle Adresse direkt anzusprechen.

 Das ist nicht wirklich verharmlosend. Es ist möglich Daten auszulesen, die nicht auslesbar sein sollten, aber die Voraussetzungen dafür sind immens hoch, und das Ergebnis kommt vielleicht gar nicht.

...zumindest nicht ohne das Schadsoftware auf dem angegriffenen Rechner läuft, und da tut's jeder herkömmliche Trojaner auch.

Und zumindest was MeltDown angeht (Spectre ist wieder eine andere Nummer), hat JavaScript (eigentlich) keinerlei Möglichkeiten die Voraussetzungen für ein gezieltes abgreifen von daten auch nur im Ansatz zu erfüllen.

(JavaScript braucht ja schon >400ms um den Finger aus der Nase zu ziehen wenn der User sich erdreistet etwas zu wollen...)

----------

## ChrisJumper

Bezüglich der gleichen CPU ...

Das ist ja eine Race-Condition, man muss ein wenig Glück haben und das Timing muss passen. Aber das was sowohl in dem Blog von Anders Fogh (Negative Result: Reading Kernel Memory From User Mode), ja schon gezeigt wurde. Muss man da (vor dem Kernelpatch und wohl Compilerpatch), bei einem noch anfälligen Rechner einfach die Adresse des anderen Speichers zur Addition nehmen wie viel speicher bereit gestellt werden muss und dann, liegt der automatisch im L1-Cache.

Das war der Punkt von dem ich glaube den Herr Schräder noch nicht so verstanden hatte. Weil er fragte sich noch wie man den RAM den man auslesen wollte, denn in den L1 Cache bekommen sollte.

 *Quote:*   

>     Mov rax, [somekerneladdress]
> 
>     And rax, 1
> 
>     Mov rbx,[rax+Someusermodeaddress]

 

 *Quote:*   

> If this is executed last two instructions are executed speculatively the address loaded differs depending on the value loaded from somekerneladdress and thus the address loaded into the cache may cause different cache lines to be loaded. This cache activity we can we can observe through a flush+reload cache attack.
> 
> The first problem we’re facing here is we must make sure the second and third instruction runs before the first one retires. We have a race condition we must win. How do we engineer that? We fill the reorder buffer with dependent instructions which use a different execution unit than the ones we need. Then we add the code listed above. The dependency forces the CPU to execute one micro op at a time of the filling instructions. Using an execution unit different than the one we used in the leaking code make sure that the CPU can speculatively execute these while working on the fill pattern.

 

Es mag sein das da unterschiedliche CPUs ein anderes Verhalten an den Tag legen, aber das muss man dann auch nur ausprobieren, Erfahrungen sammeln und den Angriff ein wenig anpassen.

Ich denke allerdings auch das der Angriff komplexer ist und man ihn noch stärker ausarbeiten muss. Hat man aber ein eingebettetes System wie mit sehr wenig Komplexität und anfälliger CPU. Ja da glaube ich schon fast das es möglich ist das System darüber anzugreifen. Sicher man muss auch noch auf das System selber drauf komme und der Code braucht wahrscheinlich auch mehrere Iterationen er durch ist.

Deswegen denke ich auch nicht das es hier ein Exploit möglich ist der Remode code Execution ermöglicht, wo ich zudem auch noch drüber nach denke ob ASLR schützt, oder es egal ist, weil der Angriff halt eine Ebene tiefer statt findet, dort wo die CPU die Adressen zwischen speichert. So das man beobachten kann welche Adressen in L1 liegen.

Das Problem ist so ein bisschen vertrackt. Eine sicher Lösung wäre einfach lange warten, wie bei einem Passwort das falsch eingegeben wurde, damit aus der Verarbeitungszeit keine Rückschlüsse auf die Komplexität oder Länge gezogen werden kann. Bei dem Cache zur Sprungvorhersage geht das halt nicht. Wenn man immer wartet.. verlangsamt sich das System so lange wie es dauern würde wenn der Code immer NICHT im Cache läge. Aber dann ist der CPU-Cache halt sinnfrei. Daher kommen glaube ich auch die Schätzungen das alles viel langsamer werden könnte.

Ich buddle mal weiter und schau mir das Paper und den Talk an youtube - Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR und das PDF

Edit: Anders Fogh hat bei der Ruhr Universität Bochum wohl einen Vortrag zu dem Thema "Covert shotgun: Automatically finding covert channels in SMT" gehalten.

Die Gute Nachricht: Das sieht wirklich nicht so aus als lässt sich leicht auch Arbeitsspeicher schreiben oder gar der Programmfluss umlenken. Sondern lediglich Informationen zur Laufzeit abhören. Stack Funktionalität hat er komplett außen vor gelassen, weil ihn die Instruktionen nicht interessiert haben. Ihn ging es hauptsächlich darum das Prozesse die sich Ressourcen teilen, auf einer CPU landen und wie man dort Informationen aus dem anderen Prozess heraus angeln konnte.

Die schlechte Nachricht:

Im Video (Youtube) von dem Vortrag wird deutlich das hier nur die Branch Prediction und deren CPU Chance angegriffen wird. Eben als klassischer Seitenkanal Angriff. Er hat da nicht gezielt die Funktionsweise der CPU Sprungvorhersage ausgehebelt oder Angegriffen, sondern einfach Ausgewertet wie oft der Speicher den er Ausgelesen hat keinen Fehlschlag erzeugte. Gefiltert hat er über die CPUID quasi das sein Angriff auf der selben CPU lief, das andere "Rauschen" (von anderen CPUs, und Interrupts) konnte er über die Zyklenzeit raus filtern. Er meinte das er später bei 77% Informationen lag, wo er nützliche Informationen angeln konnte, die er aus dem Hintergrundrauschen raus gefischt hat.

Unsicher bin ich mir jetzt allerdings wirklich bei der Frage ob M. Schräder nicht doch recht hatte. Aber meine Vermutung ist nach dem Info-Update das er wahrscheinlich das Rauschen nicht so zuverlässig ausgefiltert hat. Die Tage schaue ich mir auf jeden Fall auch mal den PoC an.

Edit2: Eklig war aber das Video zu Bypassing SMAP and Kernel ASLR (wahrscheinlich die Spectre-Lücke) und da lassen sich eventuell Informationen fischen die für einen anderen Angriff auf den Stack nützlich sind. Doch die Beschreibung liest sich auch (nur) so als beschreibt sie lediglich den Branch Prediction und man kann sich da keine Shell klicken. Was natürlich bei dem Browser fatal war, wenn die Grenze zwischen Interpreter und Skriptsprache verschwimmt. Aber die Dinger laufen ja auch noch nicht mit root.

Dennoch für Nutzer bei denen ein Browser das OS ersetzt, reicht es halt aus diesen an die Wand zu nageln um alle Surfinfos, Mails oder Bilder mit fischen zu können.

Ach ja die meinen in dem Video Bypassing SMAP und Kernel ASLR halt auch mit PTI-Patch noch geht, wenn man über Treiber kommt. Doch die Treiber haben ja eh Ring 0... wahrscheinlich war das eher so ein hüpfen aus der Sandbox oder VM-Bug. Kann jetzt vorerst wieder ruhiger schlafen.

----------

## schmidicom

Ein gutes hat Meltdown und Spectre wenigstens, es zeigt einfach wieder einmal das was die Devs rund um Linux leisten.

```
$ uname -a

Linux slap 4.15.0-gentoo #1 SMP Mon Jan 29 21:17:35 CET 2018 x86_64 Intel(R) Core(TM) i7-6700T CPU @ 2.80GHz GenuineIntel GNU/Linux

$ cat /sys/devices/system/cpu/vulnerabilities/meltdown 

Mitigation: PTI

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 

Vulnerable

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 

Mitigation: Full generic retpoline
```

----------

## ChrisJumper

Ja das ist wirklich eine Leistung!

Bei mir steht bei spectre_v2:

 Vulnerable: Minimal generic ASM retpoline

statt wie bei dir:

 Mitigation: Full generic retpoline

Ich muss noch zum neuen gcc wechseln damit das return trapoline etwas bringt. Jetzt die Frage, springe ich direkt zu 7.3 oder erstmal zu 7.2? Anschließend wohl auch das komplette System neu bauen.

Dann muss ich mir auch merken den 4.15 Kernel noch mal neu zu bauen.

Nutzt du auch das Microcode Update für Intel-Prozessoren? Da hab ich bisher auch noch mit gewartet weil ich mehrere Updates bündeln wollte wenn ich mehr Zeit hab. Für den Fall das etwas schief läuft.

----------

## schmidicom

 *ChrisJumper wrote:*   

> Jetzt die Frage, springe ich direkt zu 7.3 oder erstmal zu 7.2?

 Ich hatte bereits GCC 7.2 daher war es nur ein kleiner Sprung, nur bei meinen Server-Installationen ist noch ein GCC 6.4 im Einsatz und dort bin ich mir auch noch nicht sicher was ich machen soll. Aber wenn dann vermutlich direkt ohne Zwischenschritte.

 *ChrisJumper wrote:*   

> Nutzt du auch das Microcode Update für Intel-Prozessoren?

 Beim Laptop (Intel) halte ich den Microcode mit "sys-firmware/intel-microcode +initramfs" schon immer so aktuell wie möglich, also "~amd64". Und bei Desktop (AMD) erledigt sich das ja über "sys-kernel/linux-firmware", was ich ebenfalls immer auf "~amd64" halte.

----------

## mike155

 *ChrisJumper wrote:*   

> Anschließend wohl auch das komplette System neu bauen. 
> 
> 

 

Wozu? 

Man kann GCC 7.3 parallel zu GCC 6.4 installieren. Den Kernel compiliert man mit GCC 7.3 - alle anderen Pakete kann man weiterhin mit GCC 6.4 compilieren.

Wenn ich mir die anderen Diskussionsforen ansehe, herrscht Einigkeit darüber, dass man den Kernel mit Meltdown- und Spectre- Mitigation-Patches schützen sollte. Inwieweit man alle anderen Software-Pakete (gemeint ist "world") mit GCC 7.3 und retpoline Optionen neu compilieren sollte - darüber gibt es unterschiedliche Ansichten. Die meisten raten zum jetzigen Zeitpunkt davon ab. Die letzte Ausgabe-Zeile von "spectre-meltdown-checker" trifft es recht gut: "A false sense of security is worse than no security at all"  :Cool: 

----------

## franzf

 *mike155 wrote:*   

> Man kann GCC 7.3 parallel zu GCC 6.4 installieren. Den Kernel compiliert man mit GCC 7.3 - alle anderen Pakete kann man weiterhin mit GCC 6.4 compilieren.

 

Geht das denn mittlerweile wieder? Bei den ABI-breaking gcc-upgrades (4->5 AFAIR) gab es extreme Probleme, und die Meinung der gcc-Entwickler war dass die parallele Installation von mehreren gccs nicht unterstützt wird. Kompilieren an sich (also nur die Verwendung des gcc-binaries) klappt, aber beim linken der stdlib wird IMMER die aktuelleste verwendet, was heißt dass beim Bauen mit 6.4 gegen die 7.3er libs gelinkt wird.

----------

## Yamakuzure

 *franzf wrote:*   

>  *mike155 wrote:*   Man kann GCC 7.3 parallel zu GCC 6.4 installieren. Den Kernel compiliert man mit GCC 7.3 - alle anderen Pakete kann man weiterhin mit GCC 6.4 compilieren. 
> 
> Geht das denn mittlerweile wieder? Bei den ABI-breaking gcc-upgrades (4->5 AFAIR) gab es extreme Probleme, und die Meinung der gcc-Entwickler war dass die parallele Installation von mehreren gccs nicht unterstützt wird. Kompilieren an sich (also nur die Verwendung des gcc-binaries) klappt, aber beim linken der stdlib wird IMMER die aktuelleste verwendet, was heißt dass beim Bauen mit 6.4 gegen die 7.3er libs gelinkt wird.

 Wenn du den gcc direkt so aufrufst, ja. Aber wir haben dafür ja gcc-config.  :Wink: 

Die "extremen Probleme" betrafen eine Änderung der ABI von std::basic_string und std::list. Ersteres wird sehr sehr häufig verwendet. 

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.  :Wink:  )

----------

## ChrisJumper

Ah das ist interessant. Ich dachte man muss halt nicht nur den Kernel mit Retpoline compiler Support bauen, sonder alles? Woher will denn sonst das Proramm, wenn nicht beim Kompilieren wissen an welcher Stelle das Return-Trampolin verwendet werden soll oder ist diese Funktion wirklich nur Kernelseitig?

Edit: Oh da lag ich wohl falsch: Mailing List Archive siehe lists.gt.net verdeutlicht das gut. Und ja, alles mit 7.3 neu zu bauen scheint aktuell Sinnlos zu sein.

Ich bauete/baue gerade alles neu, hab aber auch schon verschiedene Programme die damit nicht klar kommen, neu gestartet habe ich bisher noch nicht.

evolution-data-server lässt sich z.B nicht bauen. Klibc, hat wohl allgemein einen Bug mit gcc 6 oder 7.

Der Fix aus dem Bug bei klibc:

 *Quote:*   

> edit /usr/portage/dev-libs/klibc/klibc-2.0.4-r2.ebuild changing the 25 line
> 
> > from 
> 
> > KV_MAJOR="4" KV_MINOR="x" KV_SUB="4"
> ...

 

Dann lief media-libs/vigra nicht sauber durch und www-misc/htdig ließ sich auch nicht kompilieren. Bin noch nicht "durch" Aber sehr viele Probleme hab ich nicht. Normalerweise hagelt es ja tonnen von Fehlermeldungen wenn was mit der stdlib nicht klappt.Last edited by ChrisJumper on Fri Feb 02, 2018 7:36 pm; edited 2 times in total

----------

## ChrisJumper

 *mike155 wrote:*   

> "A false sense of security is worse than no security at all" 8)

 

Das Zitat soll zum Ausdruck bringen, das wenn du zum Beispiel keinen Anti-Viren Schutz nutzt oder keine Firewall, dir dennoch Gedanken machen solltest wie das System funktioniert und zum Beispiel nicht viele Anwendungen laufen lässt, von denen man nicht weiß was sie machen, die aber dann per Default lauschen (Firewallbeispiel) oder man ohne Antivieren System vorsichtiger agiert als sich "Sie sind Sicher" Ausgaben von Schlangenöl, Anti-Viren Verkäufern oder Intrusion Detection Losungen oder zum Beispiel Deep Packet Inspection...

Bei Meltdown-Spectre betrifft das im Besonderen Hardware-Architekten, die dachten wenn Sie vorher und Nachher die normale Prozedur durchlaufen, passiert nichts schlimmes. Sie hatten quasi auch eine falsche Vorstellung von Sicherheit, weil auf dem Papier ja alles normal läuft. Tolles Beispiel für ein Design-Problem. Das ist dann auch der falsche Sinn für die Sicherheit.

Das Problem war aber das über den Seitenkanal-Angriff auf die Sprungvorhersage und den CPU-Cache aber zusätzliche Informationen abfließen, und man letztlich kurzzeitig beim Programmfluss falsch Abbiegen konnte.

Ich lag Anfangs noch stärker im Unklaren Informationen zu den drei Lücken wurden ja vermischt. Die schlimmere Lücke scheint ja eindeutig Spectre 2 zu sein, wo man über Breach Predition Injection, ja quasi doch einen eigenen Ausführungs-Zweig in die Sprungvorhersage injezieren, der wenn ausgeführt auch einigen Schaden anrichten kann.

Update: Zu den Paketen die bei mir nicht durchgelaufen sind: Das war nur bei dem einen Rechner so, zwei weitere liefen mit 7.3 ohne Probleme durch. Wahrscheinlich liegt der Fehler ganz woanders oder an der Konfiguration.

Das neu bauen ist ohne änderungen der Compilerflags aber Sinnlos, am besten wartet man auch noch neuere gcc Versionen ab die dann später (retpoline) unterstützen. mv hatte im dem englischen Thread schon neue Compilerflags getestet, aber teilweise probleme beim Compilieren und er schreibt das xorg-server und x11-drivers Pakete, sich mit dem Compilerflag [/i]-fno-plt[/i], zwar Compilieren ließen, aber X startet nicht mehr, erst als er sie wieder mit plt neu gebaut hatte.

Also erst mal abwarten und die Finger still halten.

PLT steht für "procedure linkage table" und ist das gesetzt werden die Funktionen über diese Tabelle aufgerufen statt direkt.

----------

## franzf

 *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.

----------

## ChrisJumper

Hmm. Ich hab auf meinen beiden Desktop-Systemen die ganzen Dinge mit 7.3 neu gebaut. Also auch mesa, den Firefox und Chromium. Eigentlich ein komplettes emerge -e world.****

Compilerfehler beim bauen waren wahrscheinlich nur da weil ich bei einigen Systemen seit 2008 kein vollständiges Emerge -e world mehr gemacht hatte. klibc schlug fehl, aber da ich mit systemd ohne initramfs starte. Benötige ich klibc wohl auch gar nicht mehr. Der Fehler das Evolution nicht lief hatte sich später auch erledigt. Bisher laufen alle Programme stabil.

Nur den Intel-Microcode hab ich dann doch nicht mehr gemacht, zum einen Weil der ja von Intel zurück gezogen wurde. Zum anderen weil fefe vermutet das er zu Hitzeproblemen führte die den Sockel beschädigen können.

***Genau genommen hatte ich mit eix eine Liste aller installierter Pakete erstellt..

```
# 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.

Ein paar Karteileichen waren da drin die ich dann noch von Hand raus nehmen musste. Manche Pakete haben ja auch Slots so das ältere installierten Slots gelistet werden aber emerge baut nur bei Angabe des Paketnamens die letzte aktuelle Version neu.. aber meistens ist das bei den Uralt-Paketen ja auch der richtige weg. Muss noch mal ein depclean machen.

----------

## Yamakuzure

 *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:nouveau neu bauen, was eine Sache von unter einer Minute wäre, hätte das sicher schon gelöst.Ich schrieb ja: "bislang".  :Wink: Spaß beiseite, das sieht mir wirklich nach einem Bug aus.

 *ChrisJumper wrote:*   

> (...)***Genau genommen hatte ich mit eix eine Liste aller installierter Pakete erstellt..
> 
> ```
> # eix -Ic > list_all_packages_now.txt
> 
> ...

 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...   :Confused: 

----------

## ChrisJumper

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...

----------

## mv

 *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: 

```
-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.

----------

## ChrisJumper

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..

```
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.

```
Für Page Table Isolation: (Ab Kernel 4.14.11, 4.9.77?) (Meltdown)

Security Options: -> Remove the kernel mapping in user mode
```

```
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
```

```
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

----------

## mv

 *ChrisJumper wrote:*   

> 
> 
> ```
>                           -> Harden common str/mem functions against buffer overflows
> 
> ...

 

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.

----------

## ChrisJumper

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.

----------

## forrestfunk81

Es scheint wohl weiter zu gehen mit den Prozessor Bugs: https://heise.de/-4039302

----------

## schmidicom

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...

----------

## Yamakuzure

 *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...

----------

## ChrisJumper

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.

----------

## LuxJux

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.

----------

## ChrisJumper

 *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.
> ...

 

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...

----------

## schmidicom

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.

----------

## ChrisJumper

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.

----------

## ChrisJumper

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.	

```

Security Options -->

[*] Harden memory copies between kernel and userspace

[*]     Allow usercopy whitelist violations to fallback to object size
```

Edit: 

```
 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?

----------

## Tyrus

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.

```

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.

----------

## Tyrus

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

```

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.

----------

## mike155

 *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?

----------

## Tyrus

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.

----------

## ChrisJumper

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.

----------

## ChrisJumper

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.

----------

## mike155

 *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...   :Crying or Very sad: 

----------

## mike155

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!

----------

## Yamakuzure

 *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.
> ...

 Weiterhin heißt es: "Wer keine virtuellen Maschinen einsetzt, braucht indes keinen Geschwindigkeitsverlust fürchten."

----------

## schmidicom

 *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.
> ...

 

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...

----------

## ChrisJumper

Mittlerweile sind alle meine Rechner mit Updates versorgt, mit dem aktuellen Microcode-update und bis auf den ältesten Rechner schaut das überall so aus:

```
grep . /sys/devices/system/cpu/vulnerabilities/*

/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW
```

Kernel 4.17.19 und intel-microcode Version: 20180807a_p20180808

Intel, ich bin zwar nicht ganz zufrieden mit der Art und Weise, aber dennoch ein Dank dafür das es im Laufe eines Jahres dann doch klappte, auch bei ca. 10 Jahre alten CPUs.

Wegen der Leistung: Das ist ärgerlich, aber ich nehme es lieber in Kauf, weil mir persönlich Sicherheit mehr wert ist als Leistung.

----------

## mv

 *ChrisJumper wrote:*   

> /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion

 

Bei mir sieht das anders aus:

 *grep -H . /sys/devices/system/cpu/vulnerabilities/l1tf wrote:*   

> /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled

 

----------

## mv

Ergänzung: Nach

```
echo always >|/sys/module/kvm_intel/parameters/vmentry_l1d_flush
```

erhalte ich

 *grep -H . /sys/devices/system/cpu/vulnerabilities/l1tf wrote:*   

> /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: cache flushes, SMT disabled

 

was vermutlich langsamer aber sicherer ist. Leider habe ich weder eine Kernel-Option noch eine andere Möglichkeit in /etc/sysctl.d gefunden, die obige Kernel-Variable zu setzen.

----------

## ChrisJumper

Danke für den Hinweis mv!

Hab hier auf dem System den kvm Treiber gar nicht in Benutzung, wahrscheinlich deswegen.

----------

## mv

Es gibt ein zugehöriges Kernel-Argument. Anscheinend sollte man dem Kernel inzwischen mindestens die beiden Argumente

```
spec_store_bypass_disable=on l1tf=full
```

übergeben, wenn man Sicherheit über Geschwindigkeit stellt. Es wundert mich, dass diese nicht Default sind, wo Linus sich doch lauthals beschwert hat, dass der sichere Modus nach den Intel-Patches auf den Intel-Prozessoren nur ein Opt-In und nicht der Default sei.

----------

## ChrisJumper

Fefe blogt über Sepctre und Meltdown, das laut Phoronix der neue 4.20er Linux Kernel teilweise 20 bis 50 Prozent Leistungseinbußen hat?! oO

Ich wollte zwar eh erst neue CPUs kaufen wenn diese auch eine Hardware Sicherung nutzen oder neue Technik haben. Aber ich fürchte langsam das uns das Thema in Zukunft noch länger begleiten wird. Vielleicht lohnt sich dann eine dedizierte Einrichtung für bestimmte Aufgaben und dort die Patches nicht zu nutzen aber die Umgebung zu härten oder die Daten vor der Verarbeitung zu prüften.

----------

## firefly

 *ChrisJumper wrote:*   

> Fefe blogt über Sepctre und Meltdown, das laut Phoronix der neue 4.20er Linux Kernel teilweise 20 bis 50 Prozent Leistungseinbußen hat?! oO

 

Wobei das jetzt hauptsächlich Intel CPUs betrifft.

----------

## mike155

 *ChrisJumper wrote:*   

> teilweise 20 bis 50 Prozent Leistungseinbußen 

 

Gut, dass Linus wieder da ist: https://lkml.org/lkml/2018/11/19/37

----------

## Yamakuzure

Gibt es eigentlich irgendwelche Berichte darüber, dass es tatsächlich mal irgendwo zu Angriffen per MeltDown/Spectre gekommen ist?

Alle was ich bisher sehen konnte, sind konstruierte PoCs... Es wäre wirlich mal interessant wie praktisch die Gefahr wirklich ist, und wie viel graue Theorie hier uns das Fürchten lehrt.

----------

## Mgiese

spec_store_bypass_disable=on hilft nicht. Kernel 4.19.8 , GCC 8.2 zum Kernel bauen benutzt und immernoch :

```

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable 
```

jemand nen tipp ?

thanks

----------

## Mgiese

habe nun gentoo-sources 5.0.7 drauf, aber leider ist mein system immer noch nicht gefixt.

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable

```
spec_store_bypass_disable=on l1tf=full
```

 uebergebe ich an den kernel.

CPU : Intel Core i5-3470

aktuelle unstable firmware ist installiert : sys-firmware/intel-microcode-20180807a_p20190420

muss man eventuell ein microcodeupdate manuell anstossen ?

danke fuer infos

----------

## firefly

AFAIK muss der microcode im kernel eingebunden werden, damit dieser beim systemstart den microcode in der cpu updaten kann. 

https://wiki.gentoo.org/wiki/Intel_microcode

Daher muss man den kernel neu bauen, wenn ein update des intel-microcode paket installiert wurde.

----------

## Mgiese

oh danke  :Smile: 

```
General setup  --->

    [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support

Processor type and features  --->

    <*> CPU microcode loading support

    [*]   Intel microcode loading support

emerge --ask --noreplace sys-firmware/intel-microcode sys-apps/iucode_tool

iucode_tool -S --write-earlyfw=/boot/early_ucode.cpio /lib/firmware/intel-ucode/*

grub-mkconfig -o /boot/grub/grub.cfg
```

und neustart  :Smile: 

```
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp

```

danke sehr !

----------

