 Ja, jeder hat vielleicht schon mal von Meltdown und Spectre gehört und Spectre 2 und Spectre NG und Spectre RSB und Spectre WTF, um etwas Lichter einzubringen, kommen jetzt dieser Talk, die zeigen uns alle vorgeschlagenen Mitigations, aber es geht trotzdem immer noch und jetzt willkommen, Moritz Mlipp, Michael Schwarz, Claudio Canella und Daniel Groß. Ja und damit auch herzlich willkommen auf dem Übersetzungsschriemen aus der Kabine und es geht gleich mit einem Video los, können wir im Saal die Lichter ausmachen bitte, was für ein chaotischer Weihnachtstag, wir haben die Leute spekulieren gehört, mit verkrampften Beuchen und stechenden Schmerzen im Auge, was für ein chaotischer Weihnachtstag, nach einem halben Jahr haben Colonel Patches für einige Angst gesorgt, Fehler Rückverfolgung und Jagden nach Warnungen, was für ein chaotischer Weihnachtstag, die Argumente waren nicht immer vernünftig, dass Kaiser gemirkt werden sollte, von einem Ingenieur gepostet, Lex von vertraulichem Speicher, im neuen Jahr wird es besser, Leute versuchen es zu replizieren, Leute auf Twitter posten Code, bricht das das Embargo, das Embargo, Meltdown und Spectre werden veröffentlicht, was für ein Start ins neue Jahr, keine Weihnachtsferien mehr, chaotisches chaotisches Weihnachten, chaotisches chaotisches Weihnachten, was für ein chaotisches chaotischer Weihnachtstag. Ja, herzlich willkommen, willkommen zu meinem kleinen Vortrag von der Leistung von Computern, ich liebe schnelle Computer, wer liebt noch schnelle Computer, wer hat dieses Jahr einen neuen Computer gekauft? Ja und wir wollen alle unsere Computer, dass die schnell sind und in so einem Vortrag haben wir einiges Material von anderen Leuten und hier zeigen wir von wem das ist und wir zeigen auch Forschungsergebnisse, wo wir mit anderen zusammengearbeitet haben und das wurde natürlich bezahlt von anderen und um alles das zu lesen, bitte das Paper lesen, aber Leistung ist einfach super und dieser Vorzeig ist über Leistung und als ich noch jünger war, der Pentium Pro Prozessor 1995, das war Wahnsinn, der hatte 150 Megahertz, das war richtig schön und es war der erste Intel Prozessor, der eigentlich einen Risk war, der nur so getan hat als wäre ein Zisk, das ist auch nett, da kann man schöne Sachen machen, die auf dem nächsten Punkt kommen und der hatte 256 Kilobyte Level 2 Cash in der CPU, das war nicht auf einem Mainboard, sondern im Prozessor selbst, das war super und der hatte Branch Vorhersage, Branch Prediction und Out of Order Execution und das kommt davon, dass wir diese Risk Emulation haben, diese Zisk Emulation auf Risk und einige Court Teile auf dem Prozessor werden ausgeführt und die Zukunft wird auch schnell sein und noch schneller, noch schneller, mehr und mehr Leistung im neuen iPhone wird Apple 16 Kilobyte Seitengröße als Standard Seitengröße und jetzt haben sie 128 Kilobyte Level 1 Cash und das sind größer als die in Intel Prozessoren, also Cash ist super auch, oh Daniela, nicht so schnell, ich bin der Geist der Vergangenheit. Okay und wie du vielleicht gesehen hast, du willst nur Leistung, aber das ist nicht alles und zum Beispiel stell dir vor gar keinen Bugs, keine Verwundbarkeiten, aber das bedeutet trotzdem nicht, dass die Software die ausgeführt wird, trotzdem sicher ist, denn Informationen kann immer noch entkommen aus der Hardware, aus deinen Leistungssteigerungen, die du hier so gefeiert hast, nicht wenn man keine Softwarefehle hat, das ist so nicht richtig, denn man kann diese Lacks durch Side Channels ausnutzen, man kann zum Beispiel Stromverbrauch angucken oder die Ausführungszeit, ja okay, dann verbraucht ein bisschen mehr Strom ja und was kann man daraus lernen, ja ganz viel und es gibt Studio Caches und noch wichtiger ist, bevor wir da tiefer reingehen ist, raus zu verstehen, was der Unterschied ist zwischen Architektur und Mikroarchitektur, alle kennen die Befehltsatzarchitektur und von x86 und das ist nur ein abstraktes Modell und in Wirklichkeit gibt es ein Interface zwischen der Hardware und der Software und wie diese Instruktionen implementiert sind, das ist festgelegt durch die Mikroarchitektur und da wird es wirklich interessant, ja ja das habe ich schon gemeint, das ist Zisk und Riskszeug, ja genau, wir wissen AMD, Atlon, Ryzen, Core i7, Xeon und so, die sind alle etwas verschieden und sind alle schnell, ist super, ja stimmt, aber es ist auch manchmal ein Problem und alle diese haben ganz viele verschiedene Elemente um die Leistung zu steigern, um verschiedene Aufgaben schnell ausführen zu können und sie haben mehrere verschiedene Architektur Elemente zum Beispiel Caches und Buffer, Vorhersager, Predicters wie der Brunch Prediction und das Nette ist, die machen alles schneller, das ist das Schöne, ja und sie sind für den Programmer völlig transparent für den Programmierer, das heißt, dasselbe Programm läuft auf verschiedenen Mikroarchitekturen und alles ist einfach nur schneller und weil alles schneller ist, in manchen Fällen haben wir auch Timing-Optimierung und deswegen haben wir Timing-Unterschiede und diese Timing-Unterschiede sind Zeit-Channel und die können wir ausnutzen, aber niemand weiß, was man daraus lernen kann, doch ganz viel, ja ja und ich habe auch über die Weihnachtsferien was optimiert, ich musste nämlich was kochen und kochen ist schön, ich wollte was kochen, ich habe das Brett vorbereitet, was zum schneiden und ich habe das Gemüse vergessen, ich habe keine Tomaten, ich habe keine Paprika, also muss ich erst mal einkaufen gehen und das dauert und dann komme ich zurück, jetzt habe ich die Tomaten und Paprika, also kann ich anfangen, die zu schneiden und dann fällt mir ein, ich wollte auch noch Spinat kochen, was mache ich denn jetzt, ich gehe schon wieder zum Supermarkt und das dauert und alle haben schon Hunger und das ist doof, aber dann kann ich endlich anfangen zu kochen, also was ich jetzt erfunden habe, das ist super, denn was ich gemacht habe, ich habe Sachen, die man auch im Prozessor macht und ich habe die aufs alltägliche Leben übertragen, aufs kochen und ich habe einen Foodcash erfunden und das ist einfach toll, denn jetzt kann ich alles darin speichern, alles darin ablegen und ich muss nicht ständig zum Supermarkt gehen, zum Supermarkt gehen. Hast du jetzt Prozessor-Caches durch kochen erklärt? Ja, das wäre relevant, das ist ja Unsinn, nee, das ist gut, ich bin der Geist der Vergangenheit und ich war hier schon vor zwei Jahren und ich habe dir damals schon was erzählt in einem anderen Vortrag, nämlich über die XXX80 Mikroarchitektur und du hast anscheinend an einigen Stellen nicht zugehört, also wiederhole ich das gerade nochmal. Für Zipio-Cache stelle ich vor, du hast eine Variable i und du willst auf die zugreifen, also es ist noch nicht im Cash, also gibt es einen Cash-Miss und dann muss man nachgucken im Hauptspeicher und das dauert eine Zeit, man schickt eine Anfrage hin und der Speicher antwortet und dann ist der Wert im Cash, das heißt beim zweiten Mal, wenn man diese Variable benutzen will, dann ist die schon im Cash und wenn man ein Cash-Miss hat, dann muss man auf das D-Ram zugreifen, das ist langsam und auf der anderen Seite, wenn wir den D-Ram-Zugriff nicht brauchen, weil der Wert schon im Cash ist, dann ist es schnell und das macht genau das, was es machen soll, es macht alles besser. Ja, aber siehst du hier kein Problem? Nein, kein Problem, das ist schneller und effizienter. Ja, das stimmt, aber stelle dir vor, wenn ein Angreifer das messen kann, er hat nur einen groben Timer und er mischt einen ganz feinen Timer und er misst, wie lange das dauert und wenn es aus dem Cash kommt, es ist sehr schnell, aber wenn es nicht im Cash ist, dann ist es sehr langsam, wie wir gesehen haben. Das heißt, was ein Angreifer machen kann, er kann einen Schwellwert ausrechnen, ob der Zugriff im Cash war oder nicht und kann daraus sehr, sehr gute Angriffe bauen, z.B. dem Flasch, z.B. die Flasch und Reload Attacke, also die Lehren- und Neuladenattacke. Was die Macht ist, ist, wir nehmen eine Adresse von einer Bibliothek, die sowohl von dem Angreifer als auch von dem Opfer benutzt wird und was der Angreifer jetzt macht, ist, er benutzt die Flasche, also die Cash-Lehren-Anweisung, um diese Daten aus dem Cash zu entfernen. Das heißt, die ist jetzt sowohl für das Opfer als auch für den Angreifer nicht mehr im Cash und jetzt kann entweder das Opfer diese Adresse zugreifen und dann wird diese Daten wieder in den Cash geladen und dann kann der Angreifer auch zugreifen und feststellen, ob der Opfer auf diese Adresse zugegriffen hat oder nicht. Das ist als Angreifer total gut, denn es ist eine sehr, sehr mächtige Angriffsvektor, wirklich. Was kann man denn damit machen? Naja, z.B. ganz einfach, indem wir nur den Unterschied zwischen Treffer und Nichttreffer im Cash anschauen, dann können wir z.B. AES-Schlüssel exfiltrieren. Wir können auch Zeitabfolgen von Tastendrücken angucken oder einen geheimen Kanal um Daten zu extrahieren über den Cash. Ja, und das kann man z.B. auch im Browser, in der Cloud, in Trusted Execution Environments machen. Oh, da kannst du überhaupt nicht beweisen, das funktioniert. Klar kann ich das, hier ist eine Demo. Das ist ein Samsung Galaxy S6 und das Opfer versucht, ein Messenger aufzumachen und dieses Programm hier, was da drauf aufpasst, braucht keinerlei Berechtigungen, aber es benutzt einfach nur den Cash und um rauszufinden, was das Opfer hier tippt. Der kann unterscheiden zwischen Buchstaben, Leerzeichen usw. Aber das sind doch nur Metadaten. Geh weg, du unterbricht hier meinen Talk, wo es um Performance geht, um über Metadaten zu sprechen. Nein, ich möchte hier weiter über schnelle Computersprechen. Also, ich habe über den Apple gesprochen und es gibt auch noch weitere interessante Features. Also, Intel z.B. hat schon seit sehr langer Zeit die Ausführung in unterschiedliche Reihenfolge, also Out of Order Ausführung verbessert und ich möchte darüber sprechen, denn Moritz hat auch schon hier über das Kochen gesprochen und ich denke, vielleicht machen wir alle Kekse während der Weihnachtsferien und üblicherweise sollen die so aussehen. Und womit wir anfangen, das sieht normalerweise so aus und dann gibt es ein paar Schritte dazwischen. Üblicherweise mischt man da Dinge zusammen, macht so kleine Kugeln und dann macht man sie platt und tut sie in den Ofen und anschließend möchte man sie in Schokolade tunken. Aber wenn man wartet, bis die Kekse schon fertig sind, dann verliert man Zeit. Das heißt, man kann Zeit sparen, indem man die Kekse während der, die die Kekse im Ofen sind, schon die heiße Schokolade vorbereitet und sobald man die Kekse aus dem Ofen rausholt, ist die Schokolade schon fertig und alles ist schneller. Man hat viel Zeit gespart. Das ist total großartig und das kann man auch mit Computern machen. Ah, Daniel, Daniel. Hörst du dem Geist der Vergangenheit nicht zu? Ich, ich, Michael, bin der Geist der Gegenwart. Es gibt noch eine ganze Menge andere Probleme. Ja, du hast da die Büchse der Pandora geöffnet. Das ist nicht gut, was du da machst. Diese, diese Reihenfolgenänderung, diese, diese Optimisierung auf Geschwindigkeit. Stell dir mal vor, die Kekse sind im Ofen und dann kannst du sie nicht in die Schokolade tippen und dann, wenn jemand die Schokolade sieht, dann weiß er schon, du machst hier schon Kekse. Ja, du willst mir jetzt wirklich erklären, dass irgendjemand rausfinden will, ob ich Kucki, ob ich Kekse mache oder nicht. Ja, das ist noch viel mehr. Wir können sehr viel mehr machen damit. Schauen wir uns das mal auf einem informatischen, von der Informatik her an. Es gibt ein Programm, da sind Variablen drin, das berechnet die Diagonale und die, das, die Fläche von einem Vier-Eck. Und wenn man sich das anguckt, Zeile für Zeile, aber der Computer, der schaut sich die Varianten an und überlegt sich, was kann man da parallelisieren? Genau, was ich gerade erklärt habe. Ja, ja, genau. Wir schauen uns da jetzt einfach nur in Illustrationen an mit Code. Und wenn wir uns das auf Hardware-Ebene angucken, dann sind es nicht mehr Code-Zeilen, sondern dann sind es Computer- Instruktionen. Also das hier ist die Out-of-Order-Execution, also die Ausführung in anderen Reihenfolge. Da passieren sehr viele Dinge parallel. Der Instruktionen-Stream geht da rein, wird im Frontend dekodiert und im Backend verteilt und wird verteilt auf die Ausführungseinheiten, die eine ganze Dinge machen können und wird von einzelnen Ausführungseinheiten dann ausgeführt. Und das wollte ich ja alles in meinem Talk über Performance-Optimierung sprechen. Was willst du mir eigentlich sagen? Ja, also klar, es ist eine gute Optimierung für die Performance, aber trotzdem, es gibt ein Problem. Ich habe einen Experiment gemacht. Schau dir mal meinen Code an hier. Ich habe zwei Zeilen Code geschrieben. Wirklich, du greifst auf einen Null-Point dazu. Ja, ist das ein Problem? Glaubst du, das tut irgendwas Sinnvolles? Denkst du, das macht irgendwas Spannendes? Ja, also ich habe es versucht zu kompellieren und mein Compiler war nicht so glücklich. Ja, was für eine Überraschung. Und mein statischer Code-Analyse-Tool war nicht glücklich, denn ich de-referenziere hierher Null-Pointer. Also zweite Zeile, diese Zugriff auf das Speicher wird nicht ausgeführt. Das ist das, was du jetzt denkst, was auch der Compiler denkt. Aber ich habe es versucht. Und was passiert? Ich mache Flash und Reload. Also ich leere den Cash und lade ihn neu, wie ich das vorhin gemacht habe. Und ich stelle fest, der Zugriff auf den Speicher passiert. Also diese Zeile wird ausgeführt, obwohl das eigentlich nicht. Ja, das ist doch super. Das passiert alles parallel. Da wird doch keine Informationen rausgetan. Ja, also du sagst, das kann ich für gar nichts benutzen. Ja, ganz genau das sage ich. Also kein Problem, dass hier quasi Spuren hinterlassen werden, wie Keks, Krüme. Kein Problem. Wenn wir diese Spuren sehen können in der Mikroarchitektur, in diesen ganzen Elementen, dann geben wir dem Namen, nennen wir das mal Transient der Ausführung, damit wir über was sprechen können, dann können wir diese Ausführung sehen. Und wenn wir jetzt übernachten, wie das tatsächlich funktioniert, wenn wir irgendwas laden vom Speicher, dann versuchen wir eine Speicheradresse zu lesen. Wir haben die Speichermanagement-Einheit, die guckt, ob wir auf diese Bits überhaupt zugreifen dürfen. Wenn die Berechtigungs-Bits in Ordnung sind, dann ist alles in Ordnung. Und dann kriegen wir die Daten von dieser Adresse. Aber wenn wir die Berechtigung nicht haben, zum Beispiel, weil wir versuchen, auf speziellen Speicher zuzugreifen, dann sagt die Speichermanagement-Einheit, nee, da darfst du nicht draufzugreifen. Und das ist genauso, wie es sein soll. Aber ja, und das ist doch auch, was hier passiert, richtig. Aber jetzt gehen wir nochmal zurück zu meinem Beispiel. Und wir kombinieren das. Also ich hatte vorhin eine Dereferenzierung von einem Null-Pointer. Das macht keinen Sinn. Aber wenn ich den Zugriff auf den Null-Pointer jetzt auf Zugriff auf Körner-Speicher, den ich nicht lesen können soll, ja, dann würde es natürlich weiterhin crashen. Ja, klar, da gebe ich dir recht. Aber ich benutze diese Daten, die ich nicht kriege und benutze das als Index auf einen Array, auf einen Vektor und greif auf den Speicher dazu. Und dann prüfe ich, ob irgendein Teil dieses Speichers tatsächlich gecached ist, also ob ich sehen kann, dass der zugegriffen wurde. Und wenn ich das mache, dann kriege ich wieder ein Cache-Dreffer bei genau dem Index, der auf die Daten zu entspricht, die ich gar nicht hätte lesen dürfen. Oh ja, das ist tatsächlich böse. Ja, das ist schlecht. Aber du zeigst dir irgendwelche Grafen, das ist von einem wissenschaftlichen Paper. Das funktioniert in der Wirklichkeit nicht, oder? Wenn wir das machen, doch, dann können wir tatsächlich Speicher vom Körner lesen, der irgendwo ist nicht sonderlich schnell, aber es ist relativ schnell. Und ich kann die ganzen Geheimnisse, die die Browser-History zum Beispiel lesen. Das gefällt dir nicht, denke ich. Ja, also das ist schon ziemlich schlecht, aber ich denke, wir können da was machen dagegen. Ja, und das nennen wir Meltdown. Okay, das ist wirklich ziemlich schlecht. Vor zwei Jahren habe ich andere Angriffe euch gezeigt, die ihr in folgenden Talks angucken könnt, aber das Problem ist wirklich offensichtlich. Man kann Kernel-Adressen lesen, obwohl man nur im User Space läuft. Und das ist wirklich ein großes Problem offensichtlich. Also warum nehmen wir nicht einfach die Kernel-Adressen und entfernen sie einfach, wenn wir sie nicht brauchen? Denn die Zugriffskontrolle in Hardware ist, wie wir gerade gesehen haben, nicht zuverlässig in jedem Fall, wenn man so einen Angriff starten kann. Aber Daniel hat es ja nicht geglaubt. Er wird es irgendwann lernen. Das heißt, wie können wir den Kernel anmappen, wenn wir nicht im User Space sind? Und dann sind die Kernel-Adressen einfach nicht mehr da. Und wenn sie einfach nicht mehr da sind, kann auch niemand darauf zugreifen. Denn Memory, was nicht gemapped ist, darauf kann man auch nicht zugreifen. Und das ist auch wirklich, was wir gemacht haben, in dem Kaiser Patch, den es jetzt für Linux gibt, für Windows, für Mac OS und etwas besserer Variante. Aber was es im Wesentlichen tut, ist, man hat den User Space auf der linken Seite mit den Anwendungen und den Kernel auf der rechten Seite. Und wir haben diese Prozessisolation durch diese Wand gekennzeichnet, sondern kann keine Daten durch. Aber mit Meltdown können die Daten durchkommen. Und wir ändern jetzt die Art, wie das Betriebssystem funktioniert. Wenn im Kernel-Mode ausgeführt wird die Daten, dann ist der User Space da. Aber wenn wir im User Mode laufen und der Angreifer versucht diesen Angriff auszuführen, dann ist einfach gar nichts hinter dieser Wand. Und das ist schön, weil Meltdown dann nicht mehr funktioniert. Ja, okay. Aber dann ist dieses Problem gelöst. Aber dann haben wir andere Sachen, nämlich zum Beispiel Leistung. Und ja, das behebt auch nur das Meltdown-Problem. Aber es gibt noch was anderes hier, wenn man zum Beispiel nachdenkt über virtuelle Maschinen. Virtuelle Maschinen? Ja, okay, gut. Das sind und Virtuelle sind keine richtigen Maschinen. Also gibt es auch keine richtigen Probleme. Wir haben virtuelle Maschinen und wir benutzen die ständig. Und natürlich, weil wir sie ständig benutzen, haben wir viele Leistungsoptimierung, z.B. für die Adjust Translation, sodass wir eine effizientere Adjust Translation machen können, eine Adress-Übersetzung von virtuellen auf physischen Speicher. Und das ist sinnvoll, ne? Es macht es schneller. Aber vielleicht haben wir hier ein kleines Problem. Das heißt, wenn wir zum Beispiel in einer virtuellen Maschine sind, zum Beispiel VirtualBox. Und dann haben wir eine PageTable und die referenziert eine physische Speicherstelle und dann wird das dereferenziert und dann kann man auf den Speicher zugreifen. Man hat diesen kleinen Schritt zwischendurch. Das heißt, die Adresse in die virtuellen Maschine wird übersetzt zu einer physischen Speicheradresse. Und diese physische Adresse ist referenziert eine physische Speicherseite und dann können wir darauf zugreifen. Und es gibt einen Lookup auf die physische Adresse. Das können wir überprüfen, ob das schon im Cash ist, durch Leistungsoptimierung. Und dann kriegen wir die Daten aus dem Cash natürlich schneller. Aber was passiert, wenn wir eine Adresse dereferenzieren in der virtuellen Maschine, die nicht da ist? Dann greift es auf gar nichts zu. Das ergibt ja auch Sinn. Ja, dann müssen wir diese Translation, diese Übersetzung gar nicht machen. Aber manche Prozessoren werden das trotzdem machen und machen den Cash-Lockup, die sie nicht machen sollten, weil es keine physische Adresse gibt dazu. Aber die virtuelle Adresse wird von der virtuellen Maschine kontrolliert. Das heißt, die können im Prinzip alles aus dem Level 1 Cash lesen. Ja, das ist auch blöd. Aber Intel hat gesagt, sie haben es behoben. Sie haben gesagt, sie haben es behoben. Das heißt, was machst du noch hier auf der Bühne? Geh weg. Also jetzt rede ich wieder über Leistung. Dieser Vortrag ist über Leistung. Und wie diese Folie hier. Und Intel hat mehr Ports und mehr Parallelismus und größere Reorderpuffer. Und das ist super. Das macht unsere Computer effektiver und effizienter und schneller. Also gucken wir andere Sachen an andere Hersteller. AMD zum Beispiel, die haben einen Perceptron basierten Vorhersagemechanismus für Verzweigung. Das ist auch toll, um zu sehen, wie Verzweigungsverhersage, Brandsprediction funktioniert. Nehmen wir mal wieder eine Analogie vom Weihnachten. Und wir haben immer gedacht, wie Santa wohl alle Geschenke schnell genug fertig haben kann. Der Weihnachtsmann weiß nicht, wer die Geschenke kriegt und wer sie nicht kriegt. Denn es gibt diese Sudo, von Sudo, diese Datei, wo die Inzidenz aufgeschrieben werden. Und der Weihnachtsmann weiß eben nicht, wer Sudo auszuführen versucht, obwohl er nicht im Sudo-Fail ist. Das heißt, was der Weihnachtsmann macht ist, der will natürlich keine bottlenecks haben, keine Flaschenhälse und will effizienter arbeiten. Also der Weihnachtsmann will die Böse- und Brav-Liste vom letzten Jahr. Und vielleicht hat man Sudo noch nicht benutzt auf einer Maschine. Und wenn man das letzte Jahr gemacht hat, dann macht man das wahrscheinlich dies Jahr auch nicht. Und üblicherweise. Und dann am Abend vor Weihnachten guckt der Weihnachtsmann, ob die Benutzer sich genauso verhalten haben wie im Jahr vorher. Und wenn er Brava kriegt, er einen Geschenk und sonst nicht. Und dann schmeißt er die Geschenke weg, die er aus Versehen schon gemacht hatte, die nicht verteilt werden solle und alle Richtigen vorhersagen. Dann hat der Weihnachtsmann einfach etwas mehr freie Zeit, wenn er richtig vorher gesagt hat. Es gibt so viele Sachen, die hier schiefgehen können. So viele Sachen. Oh, es geht um Weihnachten und Geschenke. Was könnte da schiefgehen? Was kann schiefgehen? Hast du schon mal von Spectre gehört? Und kann diese Optimierung kann ausgenutzt werden, die du für den Weihnachtsmann erfunden hast. Und wie funktioniert das? Also jetzt reden wir wieder über Informatik, denn diese Weihnachtsleistungssteigerung, okay, wir reden jetzt mal wieder über die Computer Informatik. Wir haben ein Code, wir haben Daten und wir haben ein Feld hier und wir können auf die Daten zugreifen. Wir haben einige, auf die wir zugreifen dürfen. Und dann haben wir Daten, das ist zum Beispiel ein Verschlüsselungsschlüssel, auf dem wir nicht zugreifen dürfen aus offensichtlichen Gründen. Und der Benutzer kann einen Index geben für den Speicher, auf den er zugreifen will, um einen String auszudrucken. Und dann, weil wir gut einen guten Code schreiben, wir überprüfen, ob der Index innerhalb des erlaubten Bereichs ist und wenn es gut ist, dann können wir nur die ersten vier Buchstaben zugreifen und dann gucken wir in eine Lookup-Table und vielleicht wollen wir einfach daraus Großbuchstaben machen. Und wenn der Benutzer das ausführt in den ersten Buchstaben, dann ist es innerhalb des erlaubten Index, aber dem man spekuliert schon, ob diese Auswertung wahr sein wird oder nicht. Und man weiß aber noch nicht, wie es ist. Aber man spekuliert einfach und sagt, ich weiß es nicht, aber ich vermute es mal, es wird falsch sein. Und in der Wahrheit ist es aber richtig. Und wenn man es wirklich ausführt, dann weiß man, ob es richtig war oder nicht. Aber man merkt es sich, wie die Liste vom Weihnachtsmann und man merkt sich, wie der Ausgang war von dieser Bedingung. Das nächste Mal fragt der Benutzer wieder nach einem Buchstaben. Das ist auch richtig. Und das war letztmal auch schon richtig. Ich vermute mal, dass es jetzt auch richtig sein wird. Denn warum sollte sich auch was ändern? Und man spekuliert, dass man macht schon vorher spekulativ diesen Speicherzugriff und dann sieht man, dass es richtig war und dann ist man schon fertig. Und man hat Zeit gespart. Es ist super. Ja, man hat Zeit gespart. Und das ist okay, solange der Benutzer ein guter Benutzer ist und nicht versucht, irgendwas Illegales zu tun. Dann sagt der Benutzer, jetzt will ich was lesen, was ich nicht lesen darf. Zum Beispiel das T hier in diesem String. Und der Benutzer gibt einen Index, der außerhalb des Bereichs ist und will dann einen von diesen Geheimwerten lesen. Der Benutzer hat in der Vergangenheit immer, immer war diese Bedingung immer wahr. Das ist wahrscheinlich diesmal auch wahr. Und ich mache einen Speicherzugriff, aber jetzt, wenn er auf diesen Speicher nicht zugreifen darf, dann mache ich diesen Speicherzugriff trotzdem und schmeißen es dann nachher weg. Oh, diesmal war es falsch. Und dann führen wir halt den L2 aus und schmeißen alles andere weg. Aber die Mikroarchitekturzustand hat sich schon geändert. Also legt man ein bisschen an Daten doch ein bisschen von dieser Bedingung vor diesem Zustand und dann macht der Benutzer weiter und liest irgendwelche beliebigen Speicherstellen. Und meistens war es wahr, dann ist es wahrscheinlich immer noch wahr. Ja, aber wer schreibt in solchen Code? Nicht alle überprüfen die, die mal überprüfte den Bereich, auf den zugreifen darf, oder? Macht ja niemand. Aber fast nicht alles, was er versucht vorher zu sagen und so CPUs versuchen nicht nur, If-Conditions, If-Bedingungen auszuwerden, sondern auch Funktionsaufrufe oder Methodenaufrufe in C++. Und dann haben wir einen Gechecks, zum Beispiel ein Animal ist ein Tier, ist ein Vogel und es gibt eine Funktion, kann es sich bewegen, kann es schwimmen oder fliegen und ein Vogel fliegt normalerweise. Also macht man die Vorhersage, ja, was ist mit Enten? Naja, meistens, nicht immer natürlich. Und dann führt man die fliegen Funktionen aus. Und die CPU merkt sich das fürs nächste Mal. Wenn man das nächste Mal wieder Bewegen Funktionen aufruft, dann Führt er schon mal Fly aus spekulativ und jetzt ist das Tier aber ein Fisch und ein Fisch fliegt normalerweise nicht. Aber es war trotzdem schon spekulativ, das Fliegen ausgeführt. Aber jetzt hat man eine spekulative Type Confusion und irgendwas, was wurde mit der falschen, falschen Daten ausgeführt. Und weil es immer noch nicht genug ist, haben wir noch mehr Vorhersagen in der CPU, zum Beispiel Rücksprünge, Returns. Wir haben hier einen Opfer und einen Angreifer und das Opfer hat ein Geheimnis, zum Beispiel ein Verschlüsselungsschlüssel und der Angreifer hat noch gar nichts und das Opfer ruft eine Funktion auf, auf einem Shortwert und der Angreifer ruft es auf Long auf und dann haben wir einen Return Stack Buffer und die CPU merkt sich vorher der letzte Aufruf kam und der letzte Funktion des Opfers läuft nur kürzer und deswegen ist der Rücksprungwert vom Opfer zuerst da ist und dann kann spekulativ der Angreifer den Wert sehen vom Opfer und dann wird es am Schluss weggeschmissen, aber trotzdem ist durch die Mikro-Architektur werden die Daten gelegt. Ja, aber das ist auch alles Meltdown-Spectre, das ist alles das Gleiche, oder? Das ist nicht das Gleiche, es gibt verschiedene Angriffe und verschiedene Probleme in den CPUs. Wenn wir zum Beispiel über Spectre-Angriffe sprechen mit Vorhersage, dann sagen wir was vorher, die CPU sagt etwas vorher und es sagt den Control Flow vorher oder den Datenfluss, je nachdem über welchen Spectre-Typ wir sprechen und das passiert nur transient, das heißt, weiß noch nicht ob es richtig ist und es könnte vielleicht weggeschmissen werden, aber irgendwann kommen die Operationen zurück und dann ist die Ausführung fertig und an diesem Moment weiß die CPU, ob die Vorhersage richtig oder falsch war und kann es dann behalten oder wegwerfen, also hat man viel Zeit gespart und das ist Spectre, aber bei Meltdown haben wir auch einige Operationen und eine Operation greift auf Daten zu und noch eine andere Operation hat eine Abhängigkeit von diesen Daten und braucht Daten aus der vorher gegenden Operation. Das ist okay, aber wenn die zweite, der zweite Befehl eine Exception hat, weil es nicht erlaubt war, weil es die Daten nicht benutzen durfte, dann ist alles, was danach geschehen ist, eine Transient-Ausführung, das hätte nicht passieren sollen, nichts sollte nach einer Exception passieren, aber die Exception kann nicht sofort stattfinden, sondern erst am Ende und das Richtige wäre jetzt, die Daten alle wegzuwerfen und die Daten abhängigen Operationen irgendwelche null oder zufällig Daten so geben, aber wenn dieser Schritt rausoptimiert wird, diesen Wert wegzuschmeißen, dann gibt es Meltdown und dann kann es sein, dass man diese privilegierten Daten, dass die liegen und also es gibt hier zwei Vulnerabilities, Meltdown und Spectre und Intel hat die schon gefixt und andere werden mit Softwarepatches gefixt, also kann ich jetzt endlich weitermachen mit meinem Vortrag über Leistung. Ja, du kannst es versuchen. Also weiter mit Geschwindigkeit. AMD, dieser Vorhersagemechanismus, der ist wirklich ziemlich großartig. Oh, Daniel, du hast immer noch nichts gelernt. Wirklich, noch mal ein Geist. Lass mich, weil du es immer noch nicht gelernt hast, lass mich den Geist der Zukunft, der jetzt sagen, was passiert, wenn du vom Pfad abweichst. Du sagst du magst Optimierung. Was würde normalerweise passieren, wenn du die Zugriffrechte aktualisierst von der Speicherseite? Was würdest du normalerweise machen? Du müsstest normalerweise ein Context Switch ausführen, aber das ist in Ordnung. Ja, du musst einen Context Switch ausführen, aber du musst auch den Eintrag ändern und im TLB-Ding ändern, das ist alles sehr langsam. Also wir haben neun Code, Intel Memory Protection Keys, also Schlüssel zum Schutz von Speichern. Man kann jetzt Bits benutzen, die vorher nicht benutzt wurden und das heißt, man kann jetzt sehr schnelle Updates machen, denn man kann die für eine ganze Menge von Zugriffe auf einmal benutzen. Aber was passiert jetzt, wenn wir dasselbe Problem noch mal sehen, das wir vorhin schon gesehen haben, denn wir können auch Mail-Down sehen mit dieser Technologie. Die Schutzschlüssel, die werden nur ganz schwach benutzt. Die Werte, die wir schützen wollen, werden nur in Transienten Instruktionen weitergeleitet. Dann kann man wieder den Cash beobachten, also das ist schlecht. Ja, das ist schlecht. Und eine andere Sache ist, wir haben Zugriffskontrolle gemacht für die den Wert von Bereichen und wir haben ne Instruktion sogar dafür, da gibt es ne x86 Instruktion dafür. Und wenn wir den außerhalb des Bereichs sind, dann kriegen wir eine Ausnahme in Exception, wir sind außerhalb des Bereichs. Aber wir wissen auch, dass die Daten in Transienter Ausführungen benutzt wird. Und jetzt können wir noch mal diese Flash und Reload Technik benutzen, um den Cash zu beobachten. Also schon wieder zwei verschiedene Varianten von Mail-Down. Ja, genau, zwei neue Varianten. Und denk dran, AMD hat immer gesagt, die haben mit Mail-Down nichts zu tun. Ja, sind sie auch nicht, oder? Ja, lassen wir uns mal angucken. Sie sagen, okay, also wir haben mit Mail-Down nichts zu tun. Das heißt, wenn ihr Linux auf einem AMD Prozessor ausführt, dann schalten wir einfach alles aus, was mit Kaiser zu tun hat. Und das haben sie 2017 schon gesagt. Das Problem ist jetzt hier. Diese erste Version von Mail-Down war auf AMD. Also man kann da nicht rauskommen, indem man das einfach ausschaltet. Und man sieht hier, dass man noch nicht mal auf Arm umsteigen kann. Denn es gibt zwei neue Varianten mit Mail-Down PR und PK, die auf Intel und AMD funktionieren. Und wir haben so viele verschiedene Varianten mit verschiedenen Problemen identifiziert, die nicht richtig funktionieren, sowohl bei Intel als auch bei AMD. Ja, aber sind wir sicher, dass die nicht funktionieren oder vielleicht auch in der Zukunft nicht funktionieren? Ja, wir sind schon ziemlich sicher. Aber wer weiß, vielleicht sind wir unsere Experimente auch falsch. Ja, wir sind auch Menschen. Ja, und du bist vor allem ein Mensch. Aber jetzt lass mal über Verteidigung sprechen. Man kann das in zwei Gruppen einteilen. Bei der ersten Gruppe wollen wir die Daten, die nicht zugegriffen werden sollten, die wollen wir entfernen. Der wollen wir, dass die über die Mikroarchitektur nicht zugriffen werden können. Ja, wir können einfach, die zweite Variante ist, wir können einfach das Problem vermeiden. Also wenn es keinen Fehler gibt, dann gibt es kein Mail-Down. Und der Geist, der Gegenwart, hat auch über Mail-Down P gesprochen. Und du hast gesagt, Intel hat gesagt, wir haben alles gelöst. Aber jetzt schauen wir uns mal an, wie die das versucht haben zu lösen. Wir können einfach das Feld für die physische Adresse löschen. Weil wenn wir diese physische Adresse von dem ungemitten PTE nicht haben, dann können wir auf den Daten im Cache nicht zugreifen. Und wir können einfach den Level 1 Cache lernen. Denn wenn der leer ist, was kann schon das Lack sein? Ja, das ist jetzt scheinbar die Zukunft. Aber wir sind ja immer noch in der Vergangenheit. Ja, denn ich glaube ja, dass das nicht funktioniert. Oh doch, doch, das funktioniert. Also was du sagst ist, du kannst, also zum allererst ist dein System komplett aktuell. Ja, ich habe es aktualisiert. Das ist ein 1804er Ubuntu. Okay, also meine Software ist komplett up-to-date. Ich habe hier eine Virtual Box. Ich habe hier ein Exploit für Foreshadow implementiert. Den mag ich wirklich gern. Wir haben eine Weihnachtsmann gesprochen. Und der Weihnachtsmann hat diese net und nicht net Liste. Alle möglichen Leute führen ja mal Sudow aus, obwohl sie kein Rot sind. Also hat der Weihnachtsmann hier diesen Manager für diese net, nicht net Liste. Und jetzt will ich meine virtuelle Maschine. Es ist nur eine virtuelle Maschine. Kommt es da nicht raus? Also wenn man aus Virtual Box rauskommt, das ist wirklich schlecht. Ich möchte den Passwort Eintrag von diesem böse net Listenmanager lesen. Vorhin konnten wir alles lesen, was im Cash ist. Also alles, was aktuell benutzt wird. Und diese net Böse Liste, die hat ein paar nette Features. Es gibt also eine Adresse, wo ich das lesen kann. Ich muss also nicht den ganzen Cash anschauen. Und du willst dann quasi das Passwort vom Weihnachtsmann lesen. Ja, aber wir kennen das Passwort nicht. Das ist das Problem. Kennt jemand das Passwort vom Weihnachtsmann? Hat jemand eine Idee, was das Passwort sein könnte? Sudow? Okay. Schauen, probieren wir das mal aus. Oh, ich kann das in Echtzeit hier angucken in meiner virtuellen, in meiner Virtual Box. Während das der Weihnachtsmann eintippt. So, I can do whatever I want, can spy on everything. Also, ich kann auf mir alles hier angucken. Ja, also in der Zukunft ist es vielleicht repariert, aber wir sind immer noch in der Gegenwart, wo das eben nicht repariert ist. Moment mal, warum ist das nicht repariert? Das sollte doch repariert sein oder nicht? Ja, es sollte repariert sein, aber es hat so viel Auswirkungen auf die Geschwindigkeit, dass es niemand wirklich macht. Oh, jetzt habe ich die Präsentation zugemacht. Das ist nicht gut. Aber wir können uns auch die Zeichnungen ein bisschen angucken. Das ist auch eine sehr schöne Demo, auch die Zeichnung von dem Weihnachtsmann. Das ist echt hübsch. Jetzt bräuchten wir den Jeopardy Sound. Ja. Und das Publikum fängt an, die Jeopardy Melodie zu pfeifen. Oh, nein, kann der wrongen. Ja. Ah, ja. Jetzt sind wir wieder am Anfang, falls ihr irgendwas verpasst habt. Ja, also fangen wir einfach nochmal von vorne an. Wo waren wir eigentlich? Ja, ich denke irgendwo da, das wäre dann schon in Ordnung. Come on. Na, jetzt? Ja, fast. Also noch mal eine kurze Wiederholung. You can do it now, fast forward. Ja, wir können das jetzt noch mal machen. Wir brauchen mehr, das können wir jetzt einfach schnell drüber skippen. Wir brauchen mehr Geschwindigkeitsoptimierungen. Ah, jetzt sind wir zu schnell. Oh, nein, oh nein. Hier, hier, genau aus hier sind wir wichtig. Wir brauchen mehr Geschwindigkeit. Aber jetzt kannst du auch wieder von der Bühne gehen. Okay, also machen wir weiter. Wir haben diese Transient-Clause. Wir haben diese Transient-Klassen. Die können wir klassifizieren. Die nennen wir alle Transient-Ausführungen. Also Transient Execution Attacks. Also, wenn wir... Also, wenn wir... Also, was ist, wenn wir die Vorhersage falsch trainieren können auf einen anderen, anderen Ort? Also, bislang haben wir nur gesehen, dass wir es auf den selben Ort trainieren können. Aber wie können wir das jetzt mit einer anderen Adresse trainieren? Warum würde ich das machen wollen? Ja, weil ich jetzt mit der Attacke was anderes als Ziel benutzen kann oder noch viel schlechter. Was könnte ich machen, wenn man die Vorhersage für die Sprünge geteilt wird? Wie könnte ich dann die Vorhersage für einen anderen Prozess, zum Beispiel vom Betriebssystem ändern könnte? Also, wir haben hier zwei verschiedene Strategien, um das falsch zu trainieren. Wir können das analysieren. Bei Intel konnten wir zeigen, dass unsere neuen Falsch-Trainier-Strategien manche funktioniert, manche nicht so richtig. Für AMD selber wie bei ARM. Mit all these variants, isn't there anything where we can say something like, we can eliminate all these variants, können wir da nicht irgendwie diese ganzen Attacke auf einmal eliminieren können? Also, wir haben die optimale Lösung. Wir nennen es die Bohrvorlage. Wenn man genau da bohrt, wo wir das hier hin gemacht haben, habt ihr auch ernsthafte Gegenmaßnahmen? Okay, also wenn ihr ernsthafte Gegenmaßnahmen haben willst, dann reden wir aber ernsthafte Gegenmaßnahmen. Also, genauso wie bei Meltdown, da haben wir drei verschiedene Kategorien. Wir können die Genauigkeit von den geheimen Kanälen reduzieren. Wir können die Spekulation ausschalten oder reduzieren oder wir können sicherstellen, dass wir das Geheimnis gar nicht zugreifen können. Und hier sehen wir, es gibt eine ganze Menge verschiedene Verteidigungsstrategien. Warum ist es so leer? Warum haben wir da schon längst verloren? Nein, die meisten Schutzmechanismen, da geht es nicht um alle Mikroarchitekturelemente. Und wenn man die nicht alle anschaut, dann kann man immer noch exploitet werden, z.B. indem man eine andere Mikroarchitekturelement benutzt. Was für die Isolierung von einzelnen Seiten kann man aber einige Boxen gesehen. Ja, ja. Und was ist das? Da wird jetzt einfach die Menge von Daten reduziert, die da zugegriffen werden kann. Und das ist in Chrome 67 schon drin und in Firefox die Arbeit nicht drauf. Und jetzt können wir uns auch eine andere Verteidigungsstrategie angucken. Wir benutzen Serialisierung. Wir führen einfach ein paar Instruktionen ein, die die Spekulation unterbinden. Und dann sollten wir auch kein Problem haben. Das haben wir auf X86 und auf ARM. Ein ernsthafter Versuch ist in Visyspec, um diese Daten komplett unsichtbar zu machen. Wie kann man dann noch Daten im Datenleck haben? Wenn wir die korrekte Vorhersage haben, dann wäre die Daten in den Cash geladen. Und wenn nicht, dann werfen wir die Daten einfach weg. Das ist aber ein Hardware. Das heißt, das kann man nicht in Software machen. Ja, das kann man in Software nicht machen. Also, wie haben wir eine gewisse Menge von Analysen dazu? Wir haben hier verschiedene Versionen angeschaut. Wir haben uns das für alle Hersteller angeschaut. Und man sieht zum Beispiel bei Invisyspec oder SafeSpec, die funktionieren auch theoretisch schon nicht. Und die Site Isolation, die funktioniert auch nicht immer. Sie funktioniert manchmal aber eben nicht immer. Ja. Das haben wir für Intel, ARM, AMD. Ja, das sieht alles ganz ähnlich aus. Ja, genau, das ist ganz ähnlich. Und wir haben auch noch ein weiteres Problem damit, denn einige, weil sie nur manche von den Fällen abdecken, das ist ziemlich schlecht. Also muss ich die gleichzeitig anmachen. Ja, man muss die kombinieren von verschiedenen Techniken. Und jede von diesen Dingern kostet Geschwindigkeit. Und das haben wir in den vergangenen Wochen gesehen, dass zum Beispiel STI BP eingeführt wurde, aber es wurde dann wieder rausgeschmissen, weil es so viel Geschwindigkeit gekostet hat. Und mit Linux 420 kann man es einschalten, aber es ist normalerweise ausgeschaltet. Also wie viele Schutzmaßnahmen hast du, die gar nicht angeschaltet sind? Also schalten wir uns noch mal die Klassifikation an. Wir haben diesen Teil hier schon gesehen. Wir haben auch schon diese Fehltraining Strategien angeguckt. Und wir haben auch früher schon gesehen hier diese ganzen Versionen von den Angräfern. Ja, denn das sind die neuen Fehltraining Strategien, wo wir zeigen. Das gibt es auch bei Meltdown genau dieselben Dinge. Wir haben einige gezeigt, die funktionieren, einige, die nicht funktionieren, eine, die wir schon kannten, einige, die wir noch nicht kannten, die auch nicht funktioniert haben und eben jetzt dann auch die die funktionieren. Okay. Wow. Das waren viele, viele Attacken. Aber wie sind wir hier eigentlich hergekommen? Ich habe das Gefühl, ich werde hier, also ihr seid mehr als ich. Also scheinbar haben wir Mikroarchitektur Attacken sehr, sehr lange ignoriert. Ich habe euch vor zwei Wochen, vor zwei Jahren erzählt, dass es solche Attacken gibt und nichts wurde getan. Und das Problem ist, wir haben Krypto- Attacken gezeigt. Ja, aber Software muss eben repariert werden. Also repariert halt die Software. Es geht gar nicht um die Sidechannels. Aber was ist mit Angriffen auf ASLR? Ach, ASLR ist sowieso kaputt. Das benutzt doch eh keiner. Das ist nicht hilfreich. Das ist eh kaputt. Das kümmert uns gar nicht. Ich benutze ASLR. Ja, aber was ist mit Trusted Execution Environments? Mit TEs? Mit Trust Zone, zum Beispiel, wo ich meine Software einfach reintuhe und alles ist sicher. Ja, die sind einfach nicht Teil des Bedrohungsmodells. Also da können wir uns gar nicht angucken. Ja, das würde ich eigentlich gar nicht so sehen. Ja, und was ist mit RoHemma? RoHemma, einige von diesen Attacken, da kann man einfach Bits umwerfen und dann kriegt man Routerechte. Ja, aber das sind nur billige Modelle. Ja, aber das, was aber das hieß, ist doch 80 Prozent der Modelle sind betroffen. Sagst du, 80 Prozent sind billig? Ja, das sage ich. So, also das heißt, ich, mir wird gerade klar, für Jahre haben wir uns quasi nur auf Geschwindigkeitskonzentriert. Vielleicht war das nicht das Beste. Ja, du stehst auf die ganze Zeit da und sagst immer nur Geschwindigkeit, Geschwindigkeit, Geschwindigkeit. Ja, da erinnert ich mich gar nicht dran. Ja, also scheinbar. Kost sind alle Optimierungen mit Kosten verbunden. Das macht bei manchen Sachen Sinn, aber bei manchen von diesen Fällen, da werden Informationen, da gibt es Informationslecks. Und wenn wir die jetzt kombinieren, diese Gegenmaßnahmen, dann kostet uns das am Ende mehr Performance, als wir ursprünglich gekriegt haben, als wir dieses Feature hinzugefügt haben. Und das ist ein großes Problem. Und weil viele von diesen Schutzmaßnahmen nicht funktionieren oder umgangen werden können, wissen wir, dass diese Transientenausführungsattacken, diese Transient-Equipment-Attacks, weiter noch lange, lange uns begleiten werden. Danke. Thank you. Thanks, Moritz, Michael, Daniel und Claudio. I think we have about 10 minutes. So, ich glaube, wir haben noch 10 Minuten für Fragen und Antworten. Also bitte fragt mal am Mikrofon 1, bitte. Da vorne ist Mikrofon 1, 2, 3, 4, 5, haben wir. Und es gibt den Signalengel dahinten noch. Also, Mikrofon 1, bitte. Danke und vielen Dank für den Vortrag. Ihr habt angedeutet, dass zum Beispiel man Prediction-Feuersage anschalten kann. Und wenn man das nicht haben will, ist das, dass man was machen kann, um das abzuschalten. Was kann man machen, um die Feuersage abzuschalten? Also, du meinst jetzt, was Software angeht? Ja, also, man kann Instruktionen einfügen, sodass der Prozessor dann die Spekulationen nicht auswirkt. Also, zum Beispiel, undefinierte Instruktionen. Oder es gibt eben Instruktionen, die der Prozessor nicht überspringt. Und ihr habt bei Michael gehört, das soll sowas machen wie L-Fans, denn nach einem L-Fans macht der Prozessor keine Speicherlade- Instruktionen, ähnlich CSDB bei ARM. Cool. Okay, wunderbar. Jetzt Mikrofon 2, bitte. Ja, wie viel, wie viel langsamer sind die Prozessoren nach dem Software oder Hardware Patch? Ungefähr so. Ja, das hängt wirklich davon ab, was für Gegenmaßnahmen man da implementiert und was für eine Art von Berechnungen man durchführt. Also, wir haben zum Beispiel diese Kaiser Patches und da hängt es massiv davon ab, was für Berechnungen macht. Beim ganz normalen Kunden, der ins Internet geht und Office ausführt, sind es vielleicht 2% oder so was. Also, das macht keinen großen Unterschied, aber wir haben zum Beispiel gesehen, was Berechnungslastige Berechnungen geht, also zum Beispiel bei Netflix. Ja, und wenn man eine ganze, viele Syscalls pro Sekunde ausführt, dann ist es wirklich wirklich schlecht und das hängt auch ganz heftig davon ab, welche CPUs hat. Also, wenn man eine neuere CPU hat, dann hat man auch weniger overhead als mit anderen CPUs. Also, es wurde zum Beispiel, dass bei diesem STI BP, das hat ungefähr 20% Performance gekostet und das ist schon wirklich eine Menge. Danke. Mikrofon 4 bitte. Hallo, vielen Dank für den Vortrag. Ich habe mich gefragt, ob ihr ihn vielleicht nur über Lesen von Daten gesprochen habt, aber wie ist es, wenn man Daten schreiben will, zum Beispiel Daten, die vom Kernel benutzt werden, anschließend oder von anderen Prozessen? Also, es gibt eine Spektrangriff, wo man quasi einen spekulativen Buffer Overflow hat, wo man die Rückgabeadresse überschreiben kann und das wird spekulativ ausgeführt und aber wir haben das noch nicht gesehen, wo man tatsächlich Persistent die Daten schreiben kann. Bei Rohammer, da kann man ein Bit im DRAM umwerfen und das kann tatsächlich persistiert, also permanent sein. Danke. Und jetzt vom Signal Engel. Gibt es Architekturen, die nicht verwundbar sind, neben denen, die ihr erwähnt habt? Ja, also es gibt zum Beispiel bei ARM einige Architekturen, die zum Beispiel für Meltdown nicht anfällig sind. Einige Firmen, Samsung zum Beispiel, hat einen Port gemacht. Bei ARM ist es nur der A75 und auch ein paar ältere, die keine Sprungvorsage haben, also keine Branch-Prediction, die, also wenn der Prozessor das Feature nicht hat, meistens sehr kleine CPUs, die embedded CPUs, die haben diese spekulativen Funktionen nicht und dann gibt es das Problem auch nicht. Aber es gab ein Paper von Joffen Burg und er hat gezeigt, dass selbst wenn man nur einen sehr kleinen Microcontroller hat, der eine gewisse Sicherheitsfeature hat, dann könnte es trotzdem Meltdown-artige Effekte geben. Danke und Mikrofon 5. Ist einer dieser Angriffe wirklich in der Freien Wildbahn gesehen worden? Ja, also ich weiß nicht, ob wir die ersten werden, die sowas wissen. Das müsste dir vielleicht jemand anders fragen. Also wir haben davon nichts gehört. Und Mikrofon 1? Entschuldigung, falls das eine dumme Frage ist vielleicht, aber es waren einige Kreise, Quadrate und Sterne in den Diagrammen. Was bedeuten die? Naja, also wenn es ein Vier-Eck ist, also ein Quadrat ist, wenn das ausgefüllt ist, dann können wir theoretisch sagen, dass funktioniert. Wenn es leer ist, dann können wir theoretisch sagen, es funktioniert grundsätzlich nicht. Und wenn es ein Stern ist, dann ist es was, was wir gezeigt haben in einem Paper. Können wir das gerade noch mal sehen hier? Bei diesem Symbol, dann heißt es einfach nur, das trifft nicht zu für diese Attacke. Also das macht keinen Sinn an dem Full. Also wir wollten die Legende nicht dazu machen, denn die Legende ist relativ lang. Aber ihr könnt das alles im Paper nach schauen. Ihr könnt in dem Paper ist dann auch die komplette Legende mit drauf. Aber leer bedeutet schlecht. Und jetzt die letzte Frage. Hallo und vielen Dank für den Vortrag. Ich bin einer der wenigen Leute, die eine exotische Architektur benutzen. Ich habe einen Power PC zu Hause, auf einer TALOS 2-Maschine und ich frage mich, ob es einen Toolset gibt, um zu testen, ob es diese Vulnerabilities auf anderen Architekturen gibt. Und ich bin nicht sicher, ob IBM... Ja, also IBM-Prozessoren sind allgemein schon betroffen. Wir wissen bei Power 8 und Power 9, ja weiß ich nicht, vielleicht auch Power 9. Die haben auch eine ganze Menge Performanceverlust, wenn man diese Schutzmaßnahmen anmacht. Also wir haben IBM-Maschinen bestellt, aber haben sie noch nicht bekriegt. Deswegen konnten wir diese Tests noch nicht machen. Aber ganz allgemein, unsere Experimente werden meistens in C-Code geschrieben. Ihr müsstet da wahrscheinlich ein paar Bits ersetzen, um das auf IBM anzupassen. Aber der Ansatz sollte sehr, sehr ähnlich sein, denn die Idee der Architektur ist so ähnlich. Danke für die Antwort. Ich werde mal das versuchen und dann meine Ergebnisse veröffentlichen. So, jetzt die allerletzte, denn wir haben nur noch zwei Minuten. Und ich glaube, hier vorne, dann Mikrofon 2. Danke, vielen Dank für den Vortrag. Ihr habt gezeigt, dass es viele neue Varianten gibt von den Angriffen. Und soweit ich verstanden habe, es gibt kein Embargo hierzu. Sind die Hilfsmaßnahmen, die Abwehrmaßnahmen funktionieren? Gibt es neue Maßnahmen oder warten wir nur auf einen Proof-of-Konzept? Ja, also ich weiß nicht, wie viele CBOs unterstützen MPK. Also es sind jetzt nicht wirklich echte Gegenmaßnahmen, die von den Herstellern kommen, aber es ist halt so ähnlich repariert, einfach die Software, wenn ihr zum Beispiel keine Vergleiche habt in der Software. Also Entwickler sollten ihre Software reparieren. Können für viele Varianten, könnt ihr die Software so umschreiben, dass sie nicht mehr dafür anfällig sind. Und wir haben da noch nicht viele Patches. Es geht auch um Risikomanagement. Also wo ist das ein Problem? Browser, JavaScript, da haben wir Side-Isolation und da machen wir diese Patches einfach aus für die meisten Applikationen. Das heißt, wir machen die Patches aus, weil die zu teuer sind und das Risiko ist einfach nicht so hoch. Das wird wahrscheinlich sich ändern, sobald es die echten Exploits gibt und dann werden die Leute sagen, na gut, mach die Patches an, ohne dass man sie anschalten muss. Aber so funktioniert Sicherheit. Es interessiert uns einfach nicht, bevor was passiert. Und nochmal eine warne Runde.