News Downfall & Inception: Neue CPU-Schwachstellen gefährden Intel- und AMD-Systeme

tomgit schrieb:
Und wie groß ist nochmal die Verteilung von ARM oder vielleicht anderen x86-Prozessoren in Produktivumgebungen, Workstations und Servern?
Achja, verschwindend gering bis nicht vorhanden. Warum sollte das dann analysiert werden? Das Interesse an Lücken bei Intel und AMD ist einfach weitaus größer und wird von den Herstellern ja teilweise gefördert.
Aber arm siehst du in mobilen devices.
Und da kann man sehr viel holen. Vorallem in Asien wo alles per Handy gemacht wird.
Aber auch bei uns spielt sich der großteil der Nutzung am Handy ab. Und wenn man da die Sicherheit schon bei der arm Architektur angreifen kann, dann ist es noch düsterer als es bei Android eh schon ist (selber nutze ich auch Android). Und ich denke, auch Apple silicon wird sicherheitslücken haben.
 
MalWiederIch schrieb:
Richtig lesen - nur bei AVX-2 und AVX-512, die zumindest in Spielen so gut wie nicht genutzt werden.
Das lässt sich leider nicht so einfach beurteilen. Denn Compiler optimieren den source code beim Übersetzen. Auch "stinknormale" Programme, die im source code nicht direkt AVX* nutzen, können im Binärcode dann mit AVX* Instruktionen laufen, wenn der Compiler das als effizienter einstuft.
Sobald also ein OS AVX oder AVX512 in den Systemanforderungen hat, sollte man davon ausgehen, das diese Instruktionen im Alltag häufig genutzt werden.

Laut den Forschern optimieren einige CPUs intern auch nochmal (siehe Can I disable the mitigation if my workload does not use Gather), so dass AVX* auch genutzt werden könnte, wenn es nicht vom OS oder Programm vorgegeben ist. Wie relevant das ist, weis ich aber nicht.
 
edenjung schrieb:
Aber arm siehst du in mobilen devices.
Trotzdem werden die meisten unternehmenskritischen Daten mit einer x86-Plattform geteilt. Entweder irgendwo als Endpunkt, Server, Workstation, oder zum Großteil in der Cloud.
Natürlich gibt es schwerwiegende CVEs ARM-Prozessoren betreffend, und mit der kontinuierlichen Migration der Cloud auf ARM-Plattformen wird auch da das Interesse steigen, aber aktuell ist das ROI größer auf x86-Plattformen als auf ARM.

edenjung schrieb:
Und wenn man da die Sicherheit schon bei der arm Architektur angreifen kann, dann ist es noch düsterer als es bei Android eh schon ist (selber nutze ich auch Android).
Die Security Posture von Android Geräten ist nicht so schlecht, wie die Propaganda es glauben lassen mag. Apps sind in Android grundsätzlich sandboxed: https://source.android.com/docs/security/app-sandbox?hl=de
Und auch sind Android-Sicherheitsupdates nur ein Teil der Device-Security, da durch u.A. Google Play Protect zusätzliche Sicherheitsfunktionen bereitgestellt werden: https://support.google.com/android/answer/2812853?hl=de
Hinzu kommen Hersteller-eigene Lösungen, wie Samsung Knox, was Android für Unternehmen durchaus ziemlich sicher und verwaltbar macht.

Auch Apples Geräte sind nicht das Fort Knox, das die Werbung suggerieren mag. Das merkt man schon alleine daran, dass es in den letzten Wochen und Monaten 4 (oder mehr) Updates gab, welche sich primär mit Plattformübergreifende Lücken in WebKit/Safari befassten.
Größter Angriffsvektoren sind und bleiben Social Engineering Szenarien. Da hilft aber oftmals selbst die beste Device Security nichts, wenn Personen Daten selbst Preis geben.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen, edenjung und Schaekel
0x8100 schrieb:
ich hoffe, du hast die nicht extra für diesen post rebootet :D
Man glaubt es vielleicht nicht aber das Teil bootet schneller als so manch moderne Plattform heutzutage. Ganz ohne SSD.

In ca. 20 Sekunden bootet MS-DOS inklusive dem Programm für die Fertigung mit dem wirklich ohne Verzögerungen oder Denksekunden on the Fly gearbeitet werden kann und auch immer diverse Parameter verändert werden müssen.

Wir fertigen damit induktive Bauelemente für Kunden wie Ferrari, Audi, Tesla, Volvo und co.

Bzw. ein Schritt der Fertigung findet an dieser Anlage, angetrieben von einem K6 statt.

Krass eigentlich. :b
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: MGFirewater, kat7, BrollyLSSJ und eine weitere Person
Snoop7676 schrieb:
Man glaubt es vielleicht nicht aber das Teil bootet schneller als so manch moderne Plattform heutzutage. Ganz ohne SSD.

In ca. 20 Sekunden bootet MS-DOS inklusive dem Programm für die Fertigung mit dem wirklich ohne Verzögerungen oder Denksekunden on the Fly gearbeitet werden kann und auch immer diverse Parameter verändert werden müssen.

Wir fertigen damit induktive Bauelemente für Kunden wie Ferrari, Audi, Tesla, Volvo und co.

Bzw. ein Schritt der Fertigung findet an dieser Anlage, angetrieben von einem K6 statt.

Sehr cool. Und das noch dazu mit 16MB (meinen K6-2 habe ich zuerst mit 64MB ausgeruestet und spaeter auf 192MB aufgeruestet). Wie ist Euer Plan, wenn die Hardware den Geist aufgibt?
Ergänzung ()

dernettehans schrieb:
Wieso gibt es bisher noch keine Benchmarks zu AMD? Gibt doch schon seit Mittwoch auch Microcode updates für Ryzen

Bei Downfall hatte Phoronix schon vorab die Information darueber, und hat Benchmarks vorbereitet, und konnte sie mit dem Erscheinen der Microcode-Patches direkt messen. Ausserdem wird da die Luecke direkt gefixt, indem die anfaellige Gather-Implementierung durch eine nicht anfaellige ersetzt wird. Bei Inception wird's wohl schwerer werden, da muss wohl auch was an der Software gemacht werden, und die Aenderung im Microcode ermoeglicht das nur.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Snoop7676
dernettehans schrieb:
Wieso gibt es bisher noch keine Benchmarks zu AMD? Gibt doch schon seit Mittwoch auch Microcode updates für Ryzen oder nicht? https://www.phoronix.com/news/AMD-Microcode-Inception
hinter phoronix steht eine person, die möglichkeiten sind da limitiert. michael freut sich sicherlich über eine subscription oder eine spende (siehe https://www.phoronix.com/phoronix-premium), dann kann er auch mehr machen.

und das verlinkte microcode-update ist für epyc. ich vermute computerbase hat nichts davon rumzustehen, um tests zu machen.
 
  • Gefällt mir
Reaktionen: Rockstar85 und Flakstar
dev/random schrieb:
Das lässt sich leider nicht so einfach beurteilen. Denn Compiler optimieren den source code beim Übersetzen.

Nö.

Bei Gentoo Linux kann ich sehr viel und sehr oft in den Compiler greifen.
Wenn ich mag kann ich AVX2 und AVXxyyy deaktivieren.
Auch Hypertreading - FAKE Kerne kann man deaktivieren.

Es soll so weit ich es weis, nur eine Instruktion davon betroffen sein.

--

Es ist ein Windows Problem hauptsächlich.
Meine gentoo toolchain ist sehr parametrisierbar.
Und es ist auch ein Problem von Webbrowser + Werbung + Verseuchte Webseiten mit Werbung die nicht kontrolliert wird. Das Thema Werbeblocker und Haftung wird wichtiger werden. Die EU soll einen Weg schaffen, damit Webseitenbetreiber mit mindestens 10.000€, Untergrenze, pro User und Webseite der einen Schaden erfährt haftet. Sollte es innerhalb von 5 Tagen nicht bezahlt werden, wird die Domain für immer gesperrt. Das Geld soll dann der User erhalten mit einer Schlichtungsstelle. Die Seuche, die einem untergeschoben wird, ist nicht mehr normal.

Sieht man sehr deutlich wenn man ein Android Tablet verwendet und gewisse Webseiten öffnet.
Von der Optik gleich, aber von der Ladeverzögerung irrsinnig.

--

Große Schadenfreude

Ich habe mir bewusst keine Intel gekauft. Bewusst eine INTEL WLAN Karte die tauschbar und überteuert ist.
Aber von den Prozessor Problemen, Netzwerkchip Probleme usw. gab es schon öfters Anzeichen in der Vergangenheit.
Jede einzelne CPU Lücke bei Intel - macht das Ding noch langsamer und unsicherer.
 
0x8100 schrieb:
wieso müssen die benchmarks nur von der einen seite kommen? amd hätte ja schon selber welche machen können ich dachte das problem ist schon seit monaten bekannt und wurde jetzt nur veröffentlicht zeitgleich mit den änderungen an Windows und Linux.

mae schrieb:
an der Software gemacht werden, und die Aenderung im Microcode ermoeglicht das nur
gibt es denn schon prognosen wie schlimm es wird bei inception zu downfall?
 
tomgit schrieb:
Hinzu kommen Hersteller-eigene Lösungen, wie Samsung Knox, was Android für Unternehmen durchaus ziemlich sicher und verwaltbar macht.

Rede bitte keinen Blödsinn.

Das MDM war nur da, damit die Geräte nicht entwendet werden
Wir hatten ein MDM auf Knox.
Ich habe von 400 Smartphones etliche Smartphones nicht mehr retour bekommen.
Und um die 20 habe ich entsperrt oder mit defekten Bootloader Retour bekommen, Samsung Galaxy Xcover 4, 4s und 5. Teilweise war dann auch privates Google Konto usw darauf und das MDM total ausgehebelt.

Das eine sind Theoretiker, die irgendetwas behaupten über Android, das andere sind Praktiker die hunderte KNOX Smartphones beruflich verwalten.

Knox ist unbrauchbar. MDM auch mit SAMSUNG
Ergänzung ()

Hito360 schrieb:
Haarspalterei - rendern Videos langsamer? wenn ja, um wieviel? 3-5% ist fuer 0815 kein Beinbruch

Man hat einen Mixed Workload.

Die Gentoo Toolchain ist dafür Verantwortlich den Code zu optimieren.

Fehlen Instruktionen gibt es erhebliche Leistungseinbussen.

Neuere Prozessoren sind "besser" weil Sie oft neue Instruktionen mitbringen die Zeit Sparen können. Fehlen diese oder werden bestehende Instruktionen "schlechter" kostet es Rechenzeit.

--

Alles richtig gemacht und eine Wegwerfcpu ryzen 7600X gekauft. CPU kann man irgendwann ersetzten, wodurch hoffentlich weniger Fehler im Silizium ist. Schade für alle - die auf alten Zeug sitzen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Rockstar85
Im Artikel steht, dass Zen 1 und 2 bei einer Korrektur heftige Einbußen hätten, aber in AMDs Bulletin steht, dass Zen 1 und 2 gar nicht betroffen sind:

"No µcode patch or BIOS update, which includes the µcode patch, is necessary for products based on “Zen” or “Zen 2” CPU architectures because these architectures are already designed to flush branch type predictions from the branch predictor."

Vielleicht hat das schon jemand geschrieben, ich wollte aber sichergehen.
 
  • Gefällt mir
Reaktionen: Volvo480
Ich hoffe doch mal stark, dass Inception nicht alle 3d Ryzen 7000 "killt", wenn diese nun öfter den Cache leeren müssen und dass es unter Windows eine Option geben wird dies wenn nötig zu deaktivieren.
 
dernettehans schrieb:
gibt es denn schon prognosen wie schlimm es wird bei inception zu downfall?

Ich habe mich nur oberflaechlich damit befasst, aber WIMRE soll bei einem Context Switch (auch zwischen User Level und Kernel Level, also ein system call) der Branch Predictor geloescht werden. Das waere fuer Code mit vielen System Calls ziehmlich uebel; code, der kaum System calls macht, sollte dagegen nicht viel davon merken. SMT wird man wohl auch abdrehen muessen, aber das bringt nach meiner Erfahrung eh wenig.
 
_roman_ schrieb:
Wenn ich mag kann ich AVX2 und AVXxyyy deaktivieren.
Sollte sowas nicht auch ganz normal im BIOS / UEFI gehen? Ich habe keine aktuellen Desktop PC hier, daher kann ich es nicht nachgucken, aber ich meine, in der Firma, zumindest bei Servern, konnte man AVX entsprechend einstellen (nur AVX, oder AVX2 oder AVX512 oder Mischung aktiviert oder alles deaktiviert).
 
Intruder schrieb:
nur erzählt einem das niemand und auch sehr viele "Cloud Jünger" wollen sowas nicht wahr haben oder glauben und loben die Cloud in den Himmel ohne an irgendwelche Gefahren zu denken. Im Gegenteil. Man stellt es zeitweise sogar so hin als ob die Cloud um ein vielfaches sicherer wäre als das eigene System zu Hause.

tomgit schrieb:
Auch wenn es die meisten On-Prem-Jünger nicht hören wollen: In vielen Fällen ist, trotz solcher Lücken, die Cloud-Lösung meist sicherer als die On-Prem Lösung. Besonders bei ohnehin überforderten IT-Abteilungen, wo auch gerne mal Updates liegen bleiben. Weil selbst bei nem IaaS-System hat der Plattformanbieter noch immer ein Interesse daran, dass die Hardware sicher ist.
Und bei sowas handelt es sich eben um eine Hardware-Lücke, welche höchstens durch die OS-Ebene mitigiert werden kann.
Im Grunde habt ihr beide recht... In der Cloud sind viele Klassische Sicherheitsmaßnahmen für angriffe von außen wahrscheinlich deutlich besser umgesetzt als On Prem. andererseit kann der Potentielle Angreifer halt mit einem auf der gleichen CPU Hocken...

Genau deshalb werden diese Lücken ja gefunden Google und Co suchen die Ja nicht zum Spaß sondern um sie zu Fixen damit der Angreifer von oben sie nicht mehr nutzen kann. Was mir in beiden Fällen mehr sorgen macht ist der Hang zur gleichheit, aka wenn du weißt wie man einen Exchange Server übernimmt ist die Chance gut das es auch beim nächsten funktioniert.
 
Zuletzt bearbeitet:
_roman_ schrieb:
Bei Gentoo Linux kann ich sehr viel und sehr oft in den Compiler greifen.
Wenn ich mag kann ich AVX2 und AVXxyyy deaktivieren.

Aber wenn man das Downfall-Paper weiter liest, steht da, dass auch nicht-AVX-Befehle wie "rep movs" (wird typischerweise von Speicherkopierfunktionen) und xsave/xrestore (verwendet vom Context switch) intern die AVX-load-buffers verwenden und damit fuer Downfall anfaellig sind. Wenn man AVX und AVX-512 ueber das BIOS abschaltet, sollte man vor der Luecke aber sicher sein, weil dann funktionieren die gather-Befehle nicht mehr.
 
  • Gefällt mir
Reaktionen: dev/random
Discovery_1 schrieb:
Der beste Schutz, wie immer, kein Computer nutzen. Man kann sich nicht gegen alles schützen, ist halt wie im Leben. Ich habe die Meldung zur Kenntnis
genommen, aber ich gehe am PC sehr verantwortungsvoll mit dem Internet um und fühle mich daher (relativ) sicher. Neues Bios kommt bei meinen AMD-Kisten auch nicht infrage, weil: "never change a running system." :D
Dann hat Dein Bios von Anfang an Deinen Arbeitsspeicher unterstützt aber bei allen Mainboards sollte beim ersten mal ein Bios Update gemacht werden da dann noch viel mehr Arbeitsspeicher unterstützt wird und Fehler gefixt wurden.
 
Steini1990 schrieb:
Eigentlich eine super Situation für die CPU Hersteller. Durch immer neu gefundene Schwachstellen werden die Kunden dazu motiviert neuere Modelle zu kaufen bei denen die Lücken nicht auftreten bzw. noch nicht gefunden wurden.

Das dachte ich mir auch gerade. Ein Schelm wer Böses dabei denkt. :)
 
  • Gefällt mir
Reaktionen: dernettehans
Zurück
Oben