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 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum
View previous topic :: View next topic  
Author Message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Mon Jan 08, 2018 4:34 pm    Post subject: Her mit euerem Fazit zu Meltdown und Spectre Reply with quote

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)
Back to top
View user's profile Send private message
forrestfunk81
Guru
Guru


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

PostPosted: Thu Jan 11, 2018 9:57 am    Post subject: Reply with quote

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.
_________________
# cd /pub/
# more beer
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 3208
Location: de

PostPosted: Thu Jan 11, 2018 8:01 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Thu Jan 11, 2018 8:38 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Thu Jan 11, 2018 10:07 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
misterjack
Veteran
Veteran


Joined: 03 Oct 2004
Posts: 1589
Location: Germany -> Saxony -> Leipzig

PostPosted: Fri Jan 12, 2018 11:29 am    Post subject: Re: Her mit euerem Fazit zu Meltdown und Spectre Reply with quote

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

Edith: passender Comic :D
_________________
„Meine Meinung steht fest! Bitte verwirren Sie mich nicht mit Tatsachen.“
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 Jan 12, 2018 1:06 pm    Post subject: Reply with quote

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:
Code:
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.
_________________
# cd /pub/
# more beer
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Sun Jan 14, 2018 12:03 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1521
Location: Schweiz

PostPosted: Thu Jan 18, 2018 7:04 pm    Post subject: Reply with quote

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. :(
Das hätte meiner Meinung nach deutlich besser laufen können...
_________________
GPG: 3FC78AEE51E5FB95
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


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

PostPosted: Mon Jan 22, 2018 1:02 pm    Post subject: Re: Her mit euerem Fazit zu Meltdown und Spectre Reply with quote

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

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.
_________________
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
Yamakuzure
Advocate
Advocate


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

PostPosted: Mon Jan 22, 2018 1:13 pm    Post subject: Reply with quote

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

Das ganze (Meltdown, nicht Spectre) schein harmloser zu sein, als es aussieht
_________________
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: Mon Jan 22, 2018 6:47 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1521
Location: Schweiz

PostPosted: Tue Jan 23, 2018 8:32 am    Post subject: Reply with quote

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/
_________________
GPG: 3FC78AEE51E5FB95
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


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

PostPosted: Tue Jan 23, 2018 3:31 pm    Post subject: Reply with quote

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

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...)
_________________
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: Tue Jan 23, 2018 8:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1521
Location: Schweiz

PostPosted: Tue Jan 30, 2018 12:19 pm    Post subject: Reply with quote

Ein gutes hat Meltdown und Spectre wenigstens, es zeigt einfach wieder einmal das was die Devs rund um Linux leisten.
Code:
$ 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

_________________
GPG: 3FC78AEE51E5FB95
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Tue Jan 30, 2018 11:46 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
schmidicom
Veteran
Veteran


Joined: 09 Mar 2006
Posts: 1521
Location: Schweiz

PostPosted: Wed Jan 31, 2018 6:47 am    Post subject: Reply with quote

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.
_________________
GPG: 3FC78AEE51E5FB95
Back to top
View user's profile Send private message
mike155
l33t
l33t


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

PostPosted: Thu Feb 01, 2018 6:14 pm    Post subject: Reply with quote

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" 8)
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 4397

PostPosted: Fri Feb 02, 2018 7:50 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


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

PostPosted: Fri Feb 02, 2018 1:32 pm    Post subject: Reply with quote

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

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. ;-) )
_________________
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: Fri Feb 02, 2018 6:55 pm    Post subject: Reply with quote

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"
> to
> KV_MAJOR="4" KV_MINOR="x" KV_SUB="14"


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
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2173
Location: Germany

PostPosted: Fri Feb 02, 2018 7:21 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
franzf
Advocate
Advocate


Joined: 29 Mar 2005
Posts: 4397

PostPosted: Thu Feb 08, 2018 7:36 am    Post subject: Reply with quote

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.
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 4:08 pm    Post subject: Reply with quote

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

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.

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.
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 1, 2, 3  Next
Page 1 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