Intel - Hardwarebug

serie300 schrieb:
Hallo

wie schaut es eigentlich mit Routern und ähnlichem aus (da ja auch ARM betroffen sein soll, MIPS weiß ich nicht). Ist so ne Fritzbox nicht ein interesssanteres Ziel für automatisierte Angriffe als ein Privat-PC?

Serie300
Zum Vergrößern anklicken....
Eine Fritzbox von außen anzugreifen ist nochmal ein ganz anderes Thema, um den Bug zu nutzen muss man zumindest irgendwie code einschleußen können (soweit ich es bisher verstanden habe).
 
serie300 schrieb:
Hallo

wie schaut es eigentlich mit Routern und ähnlichem aus (da ja auch ARM betroffen sein soll, MIPS weiß ich nicht). Ist so ne Fritzbox nicht ein interesssanteres Ziel für automatisierte Angriffe als ein Privat-PC?

Serie300
Zum Vergrößern anklicken....
Wenn nicht schon eine SW drauf ist (die Lücken gibt es ja immerhin seit 1995 oder so), dann müsste sie irgendwie den Weg auf deinen Router finden und dort ausgeführt werden. Das dürfte ziemlich schwer sein, einem einigermaßen normal konfigurierten router so etwas zu vermitteln.
Allerdings weiß ich aus Deutschland auch um Fritzboxen (und möglicherweise andere Router), die nicht dem Anwender gehören, sondern dem Provider und der versorgt die auch von außen mit Updates und neuer SW. Ich denke, inwieweit man seinem Provider trauen kann, muss jeder selbst entscheiden, aber ich vermute mal, dass die nicht unbedingt auf neue Sicherheitslücken angewiesen sind, um an allerhand Daten kommen zu können.

Ich will das Problem jetzt nicht klein reden, es ist schon sehr dramatisch, so weit ich das verstanden habe. Für mich persönlich sehe ich derzeit gar keine Gefahren dadurch. Da gibt es andere Dinge, um die ich mich eher sorge. Ich denke, der große Rummel entsteht dadurch, dass zum Einen "Sicherheit" drin vorkommt und ziemlich jeder sich betroffen fühlen muss, zum Anderen viel Geld im Spiel ist. Spekulationen an den Börsen wollen schließlich auch durch Nachrichten beflügelt werden.
Meine eigene Gelassenheit erkläre ich mir auch dadurch, dass ich wegen meines grundsätzlichen Misstrauens immer schon davon ausgegangen bin, auf einem PC nicht wirklich verlässlich privat sein zu können. Tief im Innersten befürchte ich ständig beobachtet und ausgespäht zu werden. Nun hat jemand dazu eine mögliche Technologie offengelegt und zeigt damit, was ich immer schon befürchtet hatte, an einem neuen Beispiel.

edit: vorhergehenden Beitrag übersehen und daher nicht berücksichtigt.
 
pit234a schrieb:
Ich will das Problem jetzt nicht klein reden, es ist schon sehr dramatisch, so weit ich das verstanden habe. Für mich persönlich sehe ich derzeit gar keine Gefahren dadurch.
Zum Vergrößern anklicken....
Leider gibts Browser und Javascript :). Ich bin mal gespannt wielange es dauert bis Lücken in den Fixes gefunden werden und über den Browser angegriffen wird.

Mich nervt der Gedanke und wird schnell dazu führen, dass ich mir für teuer Geld neue Hardware kaufe
 
Ich habe nun mal einige Benchmarks mit meinen Real World Workload gemacht. Über das Gesamtsystem sehe ich auf Skylake-Prozessoren durch KPTI einen Leistungsverlust von 1,83%. Am Größten ist der Einfluss wie erwartet bei den Filescannern (überwachen ein Verzeichnis und lesen hineingeworfene Dateien ein) mit 3,45%. PostgreSQL und Apache Solr liegen mit warmgelaufenen Caches je nach Querykomplexität zwischen 2% und 3%. Damit bewegt sich der Einfluss schon fast in Bereichen, die man auch durch das Powermanagement oder einfach neue Kernelversionen sieht. Das ist nun mein Workload, anderer Workload mag andere Beeinflussung sehen. Aber mit erscheinen die bis zu 5% Leistungsverlust, die die Linux-Kernelentwickler angegeben haben, wesentlich realistischer als die teils über 50%, die sich durch irgendwelche synthetischen Benchmarks, welche ausschließlich besonders betroffene Bereiche messen. Dazu kommt, dass vor allem Dinge langsamer werden, die bereits langsam waren. Vor allem Syscalls. Die hat man in realer Software schon bisher vermieden, eben weil sie langsam waren.
 
Yamagi schrieb:
wesentlich realistischer als die teils über 50%,
Zum Vergrößern anklicken....

In großen VM Umgebungen beläuft sich der Performance-Verlust allgemein wohl so um die 20%. Gerade das klassische VM -> Apache -> PHP -> Datenbank. Geht halt an jeder Stelle (VM/Apache/PHP/Datenbank) im Mittel 5% verloren (mehr Overhead durch die VM) und man kommt dann an die 20% ran.

Dass man das nicht simpel aufaddieren kann ist mir übrigens klar, obwohl es gerade schön passt. :D Hängt natürlich auch davon ab was für eine CPU unter dem ganzen Kram hängt. Skylake verträgt die Patches besser als ein Haswell z.B.
 
Ja, klar. Das war eine Milchmädchenmessung von mir, vor allem sehr auf den Workload bezogen und schon daher nicht unbedingt generalisierbar. Ganz besonders blöd ist es natürlich, wie du schon sagt, wenn mehrere Faktoren zusammenkommen. Hypervisor unten drunter, seine VM Entries und Exists werden deutlich teurer. Wenn die Host Node gut ausgelastet ist und er häufig zwischen den VMs wechseln muss umso mehr. Dann schlecht optimierter Anwendungscode. Und so weiter.
 
SolarCatcher schrieb:
Und langsam kommen die spannenden Mailinglisten-Beiträge von Theo zum Vorschein, in denen er uns schon immer vor derartigen Problemen gewarnt hat - hier in 2007 anlässlich der Bugs in Intels Core 2 Chips. Und hier - ebefalls in 2007 - sein vernichtendes Urteil über die Sicherheit von Virtualisierung à la Xen auf der Basis schlechter x86 Chip-Architektur.
Zum Vergrößern anklicken....
Seit 2007 hat sich viel getan und Theo hatte es bei den Mails oben noch über gewisse Problematiken von x86_32, welche mit x86_64 teilweise verschwunden (umbaut) sind:

Einführung von W^X in OpenBSD by Mike Larkin
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Darin erklärt er ganz gut wie simpel es bei x86_64 war und welche Hölle bei x86_32 (Kritik an der Architektur quasi)

EDIT: Die Mails gingen letztes mal bei der Einführung von vmd rum :)
 
suiyuan schrieb:
Ist dieser Bug mit Heartbleed von vor ein paar Jahren vergleichbar? Also im Umfang.
Zum Vergrößern anklicken....
Jaein :)
Prinzipiell vorerst weniger schlimm, da man Code auf der Maschine ausführen muss, aber auch irgendwie schlimmer da er sich auf Hardwareebene befindet und somit nur durch Workarounds umschifft werden kann, somit bleibt der Bug dauerhaft, bis zum Hardwarewechsel

Sind jedoch beides Infoleaks aus dem Memory


Edit:
midnight schrieb:
Mozilla bestätigt webbasierten Execution Vector für Meltdown- und Spectre-Angriffe.

https://www.bleepingcomputer.com/ne...tion-vector-for-meltdown-and-spectre-attacks/

Ich denke, das war zu erwarten. JS kann alles tun, und dazu gehört auch der Diebstahl unserer Daten.
Zum Vergrößern anklicken....
Hier wird chromium mit pledge() sehr interessant :)
 
suiyuan schrieb:
Ist dieser Bug mit Heartbleed von vor ein paar Jahren vergleichbar? Also im Umfang.
Zum Vergrößern anklicken....

Der Umfang ist an sich größer, da für ein Teil der Angriffe ALLE Computersysteme verwundbar sind (Spectre), für einen anderen Teil nur quasi alle Intel CPUs und ein paar ARM CPUs auch die von Apple anscheinend (Meltdown). Man muss jedoch erst mal den Schadcode auf die Maschine bekommen.

Heartbleed war aber praktisch etwas "böser", da man hier einfach nur von irgendwo aus alle Server "abfragen" konnte.

Das Resultat ist aber insoweit schlimm, da wir stellenweise die CPU-Fortschritte der letzten Jahre in die Mülltonne werfen können. Das dürfte Intel relativ hart treffen. AMD ist bisher nicht so hart davon betroffen, da sie intern etwas anders arbeiten und die meisten Attacken gar nicht erst funktionieren. Je nachdem wie Intel und das Server-Umfeld reagiert, könnte es durchaus sein, dass Intel hier massiv Marktanteil verlieren könnte.
 
Das große Problem ist auch nicht unbedingt Meltdown. Das ist kurzfristig böse, aber wenn die Patches erst einmal verteilt und eventueller Leistungsverlust angefangen, ist die Sache aus technischer Sicht gegessen. Anwälte und Gerichte mag es aber noch länger beschäftigen. Das eigentliche Problem ist wie @-Nuke- sagte erst einmal, dass über viele Jahre bis über das Erbrechen heraus optimierte Microarchitekturen in Frage gestellt sind. Da muss man zurück ans Reißbrett, die hochkomplexen und vielleicht gar nicht mehr in ihrer Gänze verstandenen Designs unter neuen Vorgaben (alleine Performance und Energieeffizienzreichen nun nicht mehr) neu durchdenken. Da müssen über Jahrzehnte entwickelte Validierungsprozesse überarbeitet und erweitert werden, was sicher auch Änderungen an eingespielten Entwicklungsprozessen verlangt. Das wird insgesamt sehr aufwändig und entsprechend teuer werden, außerdem Jahre in Anspruch nehmen. Und es trifft natürlich diejenigen am meisten, deren Investment am Größten ist.
Intel mit ihren etlichen Designteams, der seit >10 Jahren optimierten Core-Architektur (bzw. mit P6 sogar über 20 Jahre) und das Pech am stärksten getroffen zu sein hat da echt die sprichwörtliche Arschkarte gezogen. Wie weit voraus mögen sie intern dem Markt sein? Sicher einige Jahre. Selbst wenn sie nun innerhalb von ein paar Monaten ein neues Stepping bringen können, was Meltdown fixt, Spectre mit all seinen Möglichkeiten rauszupulen dürfte sich erst in einigen Generationen realisieren lassen. Außerdem verdammt viel Hirnschmalz erfordern, gerade wenn man vorhandene auf Core optimierte Software und Compiler nicht schlechter stellen will, weil diese Optimierungen letztendlich bares Geld sind. Und mit Pech ist Spectre erst der Anfang, wer sagt uns, dass nun wo das Thema Aufmerksamkeit hat nicht noch ganz andere CPU-Probleme mit ähnlichem Impact auftauchen?

Dazu kommt im größeren Maßstab, dass nun auch den letzten Personen klar geworden sein dürfte, dass man nichts und niemanden vertrauen kann. Will man seine geheime, für das Unternehmen wertvolle Arbeit wirklich noch auf einer Maschine machen, auf der nebenbei ein Browser mit Javascript-Engine läuft? Lässt es sich nun noch vertreten massenhaft Aufgaben in die Cloud auszulagern? Es ist wahrscheinlich naiv nun ein Umdenken zu erwarten. Aber es könnte ein großer Tropfen in das "IT ist inhärent unsicher"-Fass sein.
 
Scheint so, als wenn die Intels CPU ab Skylake so gut spekulieren, dass sie sogar die (einfachen) Gegenmaßnahmen gegen Spectre aushebeln und wieder verwundbar sind. Die einzige Möglichkeit scheint ein Microcode/Firmware Update zu sein, welches noch mal einen Performance-Hit oben drauf packt. D.h. wir reden jetzt nicht mehr von 5% im Regelfall, sondern wohl 10-15%. Alles auf Skylake und neuer.

https://twitter.com/never_released/status/949231568509267968

Es gab auch eine LKML Mail, aber ich finde die gerade nicht.

Benchmarks auf Reddit nach BIOS Update:
https://np.reddit.com/r/pcmasterrace/comments/7obokl/performance_impact_of_windows_patch_and_bios/
 
Es ist eine Scheiße... Für Intel findet sich das experimentelle Firmware-Update für die Lake-Familie hier: https://launchpad.net/ubuntu/+source/intel-microcode/3.20171215.1 Es implementiert "Indirect Branch Restricted Speculation" (IBRS) und "Indirect Branch Prediction Barrier" (IBPB) über eine MSR, die beiden Funktionen brauchen aber Unterstützung durch die Software. Unter Windows ist die Unterstützung Teil des großen Updates gegen Meltdown und Spectre, für Linux findet sich die Patch-Serie unter https://lwn.net/Articles/743019/. Dazu kommt eine Änderung am Verhalten der LFENCE Instruktion.

Für FreeBSD ist der sysutils/devcpu-data Port gerade mit aktuellem Intel-Microcode aktualisiert worden. Ich weiß nicht, ob er diese Features schon hat, aber da FreeBSD die softwareseitige Unterstützung noch fehlt ist es nicht sooo wichtig. Und vielleicht sollte man mit experimentellem Microcode auch etwas vorsichtig sein. Es kann sehr interessante Nebenwirkungen haben.

Auf AMD-Seite zirkuliert ein Microcode-Update für alle Zen-CPUs, was das Verhalten der Branch Prediction verändert. Das soll ebenfalls gegen Spectre helfen. Es gab das aus einer schlecht formulierten SuSE-Changelog kommende Gerücht, dass es die Branch Prediction komplett abschaltet, aber das stimmt nicht. Tatsächlich soll der Performance Einfluss "negligible" sein, aber belastbare Benchmarks habe ich noch keine gesehen.

Noch mal etwas abwarten, wenn aber im Frühjahr der erste Ryzen-Refresh kommt, wechsele ich eventuell von Skylake dahin. Ich wollte das eigentlich bis 2019 rauszögern, aber die Ereignisse haben meine Planung etwas überholt. ;) Ich bin aber auch in der glücklichen Lage, dass ich nur Mainboard und CPU bräuchte, alles andere inkl. dem gerade sündteuren RAM habe ich.

Nachtrag: Das Microcode-Update für Zen findet sich unter https://download.opensuse.org/repos...ts/src/kernel-firmware-20180104-205.1.src.rpm Unter Linux braucht es einen Kernelpatch aus https://github.com/torvalds/linux/commit/f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf um es einspielen zu lassen, sehr wahrscheinlich bräuchten *BSD die Änderung auch.
 
Gibt es irgendwo ein Changelog aus denen sich die Änderungen ersehen lassen, die die Microcode-Updates mit sich bringen?
 
midnight schrieb:
Mozilla bestätigt webbasierten Execution Vector für Meltdown- und Spectre-Angriffe.
https://www.bleepingcomputer.com/ne...tion-vector-for-meltdown-and-spectre-attacks/
...
Zum Vergrößern anklicken....

Kann mir das hier einer mal etwas erklären?
So wie ich das jetzt verstanden habe, muss für Meltdown und Spectre Code auf dem Rechner ausgeführt werden, heißt jede Anwendung auf dem Rechner könnte die Lücke benutzten. Aber wie zur Hölle soll das über JavaScript aus einer Webseite funktionieren? Seit wann hat Javascript so tiefen Zugriff auf das System das das möglich ist? Oder haben die Browser/JS-Engine so derbe Sicherheitslücken das da durch Meltdown/Spectre über JS möglich sind? Das wäre aber doch dann eine Kombination aus verschiedenen Sicherheitslücken?

Mir ist klar das Browser immer wieder Probleme haben und JavaScript das AIDS des Webs ist, aber wie das zusammenhängt, ist mir unklar. Da kann ich mich genauso gut hinstellen und sagen "Jede Anwendung die Code aus anderen Quellen nachlädt und ausführt eignet sich für Meltdown/Spectre"?
 
gadean schrieb:
Seit wann hat Javascript so tiefen Zugriff auf das System das das möglich ist?
Zum Vergrößern anklicken....

Ob C, JavaScript, Ruby, Python oder sonst was... es wird Code auf deinem PC ausgeführt, das reicht für Meltdown und Spectre. Du brauchst keinen "tiefen" Zugriff. Du brauchst nur beliebigen Code irgendwo. Das ist das Schöne an Seitenkanal-Angriffen.
 
gadean schrieb:
Kann mir das hier einer mal etwas erklären?
Zum Vergrößern anklicken....
es ist weiter oben eine Seite verlinkt, die auch zu den Beiträgen der TU Graz führt. Darin erklären die das ziemlich genau auch anhand von Code-Schnipseln. Ich verstehe das nicht, aber ich sehe darunter Szenarien mit JS und mit verdammt wenig Code. Das scheint kein Hexenwerk zu sein.
 
Ok das mit dem "tiefen Zugriff" ist etwas unpassend Formuliert, gemeint war damit eher seit wann man über JS auf den Arbeitsspeicher zugreifen kann, aber ich hab mir jetzt das Paper zu Spectre nochmal näher angeschaut (den JS Teil) und bin echt überrascht. Ich verstehe bei weitem nicht alles davon, aber das was ich sehe und versteht, verschlägt mir den Atem.
 
gadean schrieb:
Ok das mit dem "tiefen Zugriff" ist etwas unpassend Formuliert, gemeint war damit eher seit wann man über JS auf den Arbeitsspeicher zugreifen kann
Zum Vergrößern anklicken....

Es greift ja auch nicht JavaScript auf den fremden Arbeitsspeicher zu, sondern der Prozessor macht das für dich durch seine spekulative Ausführung und seinem Out-of-Order Design.

Du "ärgerst" den Prozessor über irgendwelchen Code nur solange bis er es tut.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben