 Also ich habe PC-Milatoren für Code-Analyse schon ziemlich lange benutzt, ich schätze irgendwie schon seit der 90er ungefähr. Hauptsächlich weil man eben an der Hardware rumformeln kann und Tricks machen kann. Aber Coemo ist tatsächlich noch viel mehr als jetzt nur irgendwie für Code-Analyse ein Emulator zu sein. Und in Zufügung von Virtual Secure Boot zu Coemo wird meiner Ansicht nach, ja, gerade im Bereich Cloud Computing sehr wichtig sein. Der folgende Vortrag von Gert Hoffmann wird sich halt eben mit den ganzen Schritten befassen, die die Auftragten um Secure Boot zum Laufen zu bekommen. Habt viel Spaß bei seinem Vortrag. Hallo, ich bin Gert Hoffmann, ich arbeite für Red Hat seit ungefähr 10 Jahren im Virtualisierungsteam für Coemo und auch an KVM und dem Kernelsatte. Eine meiner Arbeitsgebiete ist Funware, deshalb gebe ich diesen Vortrag heute. Zuerst möchte ich über einige Terminologie gehen, worüber ich in diesem Vortrag reden werde. Und wie man eine Plan baut, um Secure Boot für virtuelle Maschine aufzubauen. Und wie man das implementiert in allen drei verschiedenen Unterprojekten. Und als nächstes dann eine kleine Instructions, wie man das macht, wenn man das selber umbasteln kann. Mit genügend Zeit vielleicht auch eine kleine Demo und natürlich am Ende Q&A. Wir beginnen mit der Thematologie, das erste ist natürlich Secure Boot. Es ist spezifiziert in der UEFI Spezifikation 2.1. Das Ziel ist von Secure Boot, dass kein nicht getrusteder Kernel auf der Maschine laufen kann. Das sind der ganzen Komponenten gestart werden. Die grundsätzliche Idee ist, jeder Komponente hat eine eigene Komponente, die sich gegenseitig checkt. Also die Firma prüft den Bootloader, der Bootloader, der Kernel und der Kernel, prüft die Module und die Treiber. Und nachdem sie in den Kernel-Adressraum geladen werden, alle diese Schlüssel dafür, um das Ganze zu benutzen, werden von der Firma verweitet. Das bedeutet, damit das Ganze funktioniert. Die Firma selber muss natürlich auch das Speicher für die Schlüssel, weißes Flash, muss geschützt werden, damit das Betriebssystem oder Malware die versuchen, das zu infizieren, das nicht modifizieren können. Und wie wir das für virtuelle Maschinen implementieren werden, sind dieses Vortrags. Als nächstes QEMO. Das ist ein Open-Source-Computer-Immulator und Virtualisierungs-Maschine. Es immoliert alles, was es an einer physikalischen Maschine gibt, also das Chipset, die Timer, die Interrupt-Controller. Natürlich auch alles, was man benötigt, um mit der Maschine zu interagieren, Grafikkarte, Keyboard und so weiter. Auch mit NVMC Server kann man natürlich dann auch dazu reden. Es ist Speicher natürlich, Netzwerk, USB. Das nächste ist KVM. Die Kernel-Virtuelle Maschine. Es ist ein Treiber für den Linux-Kornel, der bereit steht für Applikationen. Auf der X68-Artektur sind die VM-Exakt-Erweiterung, die SAP-VM-Erweichung. Auf RM ist das der Hype-Mode und für andere Architekturen, die auch unterstützt werden, benutzt QEMO, also aktuell KVM für die CPU-Virtualisierung. Der Code von der virtualen Maschine läuft direkt auf der richtigen Maschine. Das ist die schnellste Variante, das zu benutzen. Die andere Option von QEMO ist TGZE, which stands for Tiny Code Generator. Es ist ein Teil von QEMO. Es wird benutzt, wenn man nicht auf der gleichen Architektur arbeitet, z.B. wenn man einen Arm-Gust auf einer X68 Maschine emuliert, dann können sie nicht direkt auf der CPU laufen. TGZE wird das übersetzen, um die Host-Instruktion und das Ganze ausführen. Und es kann natürlich auch genutzt werden, um CPUs ohne Virtualisierungssupport zu benutzen. Manchmal, wenn man Dinge auf KVM benutzt, ist es manchmal zu schnell, insbesondere für alte Gastsysteme. Z.B. ein altes Windows-System, das auf einer ganz bestimmten Version wird. Wenn man das auf einer heutigen Hardware mit KVM benutzt, ist es so schnell, dass die Kalibrationsschleife so schnell läuft, dass Windows abstürzt. Der leichte Fix ist, KVM abzustellen und dessen TGZE zu benutzen. Nächstes, EDK2. Das steht für EFI Development Kit Version 2. Das ist die Referenzimplementation für UEFI. Zuerst auf tianocore.org und der Source Code ist auf GitHub zur Verfügung gestellt. Mehr interessant für QEMO ist OVMF, Open Virtual Machine Firmware. Es ist eine X68 UEFI Implementation für QEMO, was in der Tat in diesem Fahrt im EFI Development Repository liegt. Es kommt mit Treibern für Viteo und VR-Geräte. Und das EDK Repository hat auch Firmware für ARM, falls man damit rumspielen möchte. Kein Feinde, der. CBIOS ist die Default-Firmware in QEMO. Also, falls man QEMO startet, und man möchte eine andere Firmware starten, bei Default bekommt man CBIOS. Man kann Coreboot als QEMO-Interface haben für das BIOS oder Coreboot als QEMO-Firmware. Das ist alles über die Thermologie. Das hier ist, wo wir vor ungefähr zwei Jahren waren. Sequre Boot Support ist in der EFI Development Kit verfügbar, schon ziemlich lange. Es nutzt OpenSSL, um die Krypto zu machen. Aber es ist nicht Teil vom Repository, sondern man muss das über den Tarbol importieren und einige Patches anwenden, weil es da in der EFI Umgebung einige Unterschiede gibt, z.B. kein Standard IO. Und dann kann man das einfach bauen, indem man die Secure Boot Enable Option setzt, und dann hat man eine Firmware mit Secure Boot Unterstützung. Aber das Problem hierbei ist, dass der Firmware selbst nicht geschützt ist. Der Speicher und der Hintergrundspeicher ist nicht geschützt. Und auch der Flash, wo die Keys rumliegen und die EFI Variablen liegen, der ist auch nicht geschützt. Das heißt, ein östartiger Gast könnte dann, wenn man noch machen, was er will. Es ist zwar noch irgendwie nützlich, wenn man z.B. Software mit Secure Boot Unterstützung entwickeln möchte, und man kann das eben nutzen, um zu überprüfen, dass man die Interfaces auf die korrekte Art und Weise benutzt. Aber es ist halt noch nicht so ganz das Ende vom Lead. Also, wenn man dann QEMO Support für irgendwas Neues entwickelt, hat man im Prinzip zwei Möglichkeiten, das zu tun. Eine Option ist, dass man ziemlich nah an echter Hardware dran bleibt. Das heißt, man emuliert irgendetwas, das in der echten Welt existiert. Und die andere Option ist, dass man etwas vollständig Neues entwickelt. Also eine komplett virtuelle Softwarelösung. Man kann ja alles machen, was man will. Das ist ja Software. Und beide Ansätze haben irgendwie Vor- und Nachteile. Das funktioniert leichter auf der Gastseite, weil die Gäste einfach diese Hardware sehen, obwohl sie nicht echt ist. Die Gäste können damit umgehen, haben schon Treiber dafür. Und das Gastbetriebssystem wird einfach in der Lage sein, diese Hardware zu benutzen. Und es ist auch normalerweise einfacher, virtuelle und physikalische Maschinen zu managen, weil es den Unterschied zwischen den beiden setups sehr klein hält. Auf der anderen Seite kann es relativ teuer sein, sowas zu emulieren. Hängt natürlich ein bisschen von der Hardware ab. Ein Beispiel sind der alten USB-Adapter, die relativ schwer zu emulieren sind in einer Wartellisierungsseite, relativ viel CPU-Zeit verbrauchen. Es gibt schon lange, aber wenn man halt ein virtuelles USB-Target an eine virtuelle Maschine verbraucht, das verdammt viel CPU-Zeit. Ein anderes Problem ist, dass man etwas limitiert darauf ist, was die physikalischen Hardware-Features können. Das wird heute zum Beispiel ein Problem mit dem Serious-Grafik-Adapter, der deswegen auch nicht mehr der Standard-Grafik-Adapter ist. Serious-Grafik-Adapter ist ein Design aus den 90ern und kann einfach nicht mehr mit den heutigen Anforderungen Schritt halten. Die andere Option ist dann, etwas komplett neu zu machen, also Paravirtualisierung. Man hat dann natürlich mehr Freiheiten im Design von den Dingen und man hat normalerweise auch bessere Performance. Wenn man es clever macht, kann man viel Code-Sharing betreiben, wo bei den ganzen Wirt-Aero-Geräten für SCSI, Network usw. Die nutzen alle das gleiche Ringformat um den Datenaustausch zwischen Host- und Gas-Bus-System zu realisieren und man kann auch einige Sachen stark vereinfachen, weil es halt eine virtuelle Maschine ist und manche Sachen einfach einfacher sind als auf physikalischer Hardware. Der Nachteil davon ist natürlich, dass man die Gas-Treiber schreiben und warten muss. Das ist nicht so ein großes Problem, wenn man jetzt nur Linungs benutzt. Die Treiber sind einfach Teil vom Körner, also man merkt es nicht so. Aber unter Windows zum Beispiel, es ist deutlich sichtbarer für den Nutzer, weil man eben ein spezielles Treiber-Image braucht, mit den ganzen Wirt-Aero-Treibern drauf. Ein Problem von Vereinfachung kann auch sein, dass es einem dann auf die Füße fällt. Es kann dann zum Beispiel auf längere Sicht Probleme geben. Zum Beispiel gab es in der originalen Wirt-Aero-Spezifikation die Sache, dass man gesagt hat, wir haben eine virtuelle Maschine. Wir wissen, welche Endien es, wir haben. Das heißt, wir nehmen einfach immer die native Endien. Das heißt, wir müssen uns da nicht um das Biteswapping kümmern. Und das war keine gute Idee, weil heutzutage, oder dieser Tage, IBM die PowerPC-Architektur auf Wirtle-Endien umstellt, die vorher Big-Endien war. Und die virtuelle Maschine startet dann aus historischen Gründen in Big-Endien-Modus. Die Firma spricht mit dem Wirt-Aero-Gerät in Big-Endien-Modus. Dann wächst es halt irgendwann in Wirtle-Endien-Modus und der wird auch irgendwie mit dem Wirt-Aero-Divis reden, aber in Wirtle-Indien. Und das macht halt alles irgendwie nicht so viel großen Sinn, gerade auch bei PowerPC nicht. Das sind also die Fallen, in die man so da reinlaufen kann, wenn man halt zu viel vereinfacht. Also, schauen wir uns mal an, wie die Firma ja auf physikalische Hardware geschützt ist. Wir haben jetzt noch eine Frage, was das heißt. Es gibt etwas, das heißt System Management heißt, alle Prozessoren seit ungefähr 20 Jahren, oder mindestens 20 Jahren haben das Feature. Und das Chipset kann halt ein Interrupt registrieren oder setzen, um in System Management Mode zu wechseln und das hält dann den kompletten Zustand des Prozessors im Speicher und führt die Ausführung an einer anderen Adresse fort. Und es gibt dann eine spezielle Instruktion, mit der man wieder in den normalen Betriebsmodus zurückwechseln kann. Es wurde zum Beispiel für Power Management entwickelt, dass man keinen speziellen Co-Prozessor braucht, um das zu realisieren, sondern das einfach das Chipset machen lassen kann, indem das Chipset halt eben diesen Interrupt wirft und dann den Power Management Code laufen lässt, also um zum Beispiel den Temperatursensor zu checken und dann die Lüftergeschwindigkeit zu regeln, zurück wie SuperSight. Es gibt halt auch einigen Speicher, dem man nur aus dem System Management auch zugreifen kann. Es ist ziemlich klein, 128 Kilobytes. Es ist ein Platz im Speicher, wo normalerweise der VGA-Frame-Buffer rumlegt und neue Chipset haben zusätzlich dazu noch eine größere Section, die T-Sack heißt und die kann bis zu 8 Megabyte groß sein und die ist dann am oberen Ende vom Speicher, also am oberen Ende vom Speicher, aber unterhalb von 4 Gigabyte, also im 32-Bit-Adressraum. Und die Konfiguration für SM-Ram und T-Sack kann komplett gesperrt werden, das heißt, sobald es initialisiert und gesetzt ist, kann es dann nicht mehr verändert werden, bis die Maschine zurückgesetzt wird. Und das heißt, die Frage ist, können wir dasselbe auf Coemo machen wie auf der blanken Hardware? Der Vorteil ist aber natürlich, wir können darauf hoffen, dass wir nicht zu viel neuen Code schreiben müssen, denn wenn wir Assistant Management Mode Q-Emo zu implementieren, dann können wir den bestehenden Code aus dem EDK2 Toolkit benutzen, um das zu handeln. Performance sollte nicht das größte Problem sein, in dem Fall, weil es dann nur beim Boot passiert. Und das Problem aber ist, dass der Assistant Management Mode für etwas anderes entwickelt wurde als Security und es hat einen ziemlich schlechten Track-Rekord in diesem Zusammenhang, also eine ziemlich schlechte Historie. Man kann da vergangenen Congress-Talks sich anschauen über Probleme im Assistant Management Mode, dass das schon ein bisschen relativ vorsichtig sein, wenn wir eben diesen Weg wählen würden. Und wir hatten bis vor kurzem auch keinen SMM-Support, also keinen Unterstützer für den Assistant Management Mode in KVM und TSG hatte nur ziemlich rudimentären SMM-Support. Das heißt, wir haben uns also trotzdem entschieden SMM zu implementieren und jetzt schauen wir uns an, wie das in Q-Emo aussieht. Also Q-Emo kann zwei verschiedene Chipsets emulieren. Das eine ist von dem ältere, in der Mitte der 90er. Das ist so alt, dass es kein TSAC Speicher hat. Also können wir das gar nicht benutzen für Secure Boot, weil die EDK2 Implementation reicht nicht, um die in den SMM-Ram zu bekommen. Wir haben das neuere Q35 Chipset Emulation. Also das kann man mit Dash M Q35 aufrufen. Wir haben einen gewissen SMM-Ram Unterstützung. Das heißt, wir müssen TSAC implementieren und wir müssen auch Lockpit Unterstützung implementieren, wenn wir versuchen wollen TSAC zu sperren und wir müssen testen, dass das auch wirklich funktioniert. Und wir müssen natürlich rauskriegen, wie man den virtuellen Flash schützen kann. Eine der Möglichkeiten, die wir nutzen können, ist die Memory API, die ist bei der gleichen Person gemacht worden, die auch das andere gemacht hat. Das tut im Prinzip das ganze Memory Management einmal von oben nach unten kehren. Alle alten Versionen von QEMO hatten ein sehr einfaches Schema, um den Memory zu benutzen. Es gab nur einen Register und es bleibt dort, bis das QEMO beendet wird. Und wenn man etwas anderes registriert, dann an der gleichen Adresse, dann geht es einfach auch weg. Und jetzt haben wir eine Hierarchie von Speicherregionen. Wir können sie jetzt hin und her bewegen, wir können andere Adressen benutzen. Das wird jetzt benutzt, um solche Adresseräume zu benutzen. Und das ist ein sehr großer Schritt vorwärts, insbesondere für solche Randfälle. Zum Beispiel, wenn man ein Netzwerkadapter arbeitet, und jetzt funktioniert das richtig, jetzt wird einfach etwas von dem Speicher verschwinden und errichtigen. Und es erlaubt uns auch, mit etwas Problem darin noch, dass jedes PCi-Gerät hat einen eigenen Adressraum für DMA. Und wenn man den Bassmasse dem Abit nicht setzt, im PCI-Context-Raum, dann schaltet man auch diese Schwacheregion nicht ab. Das bedeutet, dass DMA seine Funktionen anstellt. Es gibt einige Treiber, zum Beispiel die 4th IO Treiber, die noch nie auf richtige Hardware getestet wurden. Und das bedeutet einige Änderungen bei diesen Treibern. Die Implementierung von SMM ist ziemlich unmöglich ohne dies. Sehen wir mal, wie das Ganze aussieht. Ein bisschen kleiner. Das ist die System-Memory Region, von dem alten ISA-PC, den wir haben, also ohne den ganzen PCI-Zock. Schön zu sehen, wie das Ganze aussieht. Das ist eine Systemregion, die den gesamten Adressraum annimmt. Wir haben den Speicher, der 128 KB groß ist, glaube ich. Wir haben ein Container, der die ganzen Unterregionen hält für die ganze Server-Satnamel. Man kann sehen, ob es genau hier sichtbar ist. Das ist dieses hier. Die anderen Regionen sind deaktiviert. Man kann die programmieren, dass die VGA Bankregister einiges von dem VGA-Speicher benutzen auf diesen beiden Bereichen. Es wird in dem einen Fall aktiviert, und es wird sichtbar sein für den Gast, weil es die höhere Priorität hat. Es wird sich überlappen. Und die eine Region ist ein BIOS. Das ist für eine ISA-Maschine. Wie sieht es aus für eine 35-Maschine? Sehr ähnlich. Wir haben die PCI-Region, die ich hier beck gelassen habe, um genug zu haben. Wir haben die SMM-Speicher-Region, die in früheren Versionen dort war, für die grundlegende Funktionen, die wir dort hatten. Was neu ist, das T-Sack-Rack-Hall, das überlappt sich mit dem oberen Rammbereich. Das ist der oberste Bereich des Speichers. Das hat eine höhere Priorität. Wenn der Gast versucht, diesen Speicherbereich zu benutzen, es würde nicht funktionieren, aber wir konnten nur FFF, nichts anderes. Auf diese Art und Weise können wir T-Sack verstecken von der normalen Systemübersicht verstecken. Wir haben auch MMI-O hier. Und MMI-Config, den Adressbereich. Das Q35-Chipset hat dort auch eine Adressöre-Adresse. Es ist deaktiviert, um zu zeigen, dass wir es nicht benutzen. Der Alias ist dort. Und wir haben für MMI-Interrupts dort zwei Speicherbereiche für den Flash. Der Flash 1 ist. Der Flash 1 ist. Und andere, wo der Code lebt. Kommt er zu später. Um den Zugift zu aktivieren, zum SMM-Modus auf den SMM-Speicher, haben wir diese Region, welche Alias so hat, zum Intrigen- und Ton-SMRAM-Luckbereich. Und dieser. Und jeder von denen, und jeder einzelne virtuale CPU bekommt das eigene Adressraum. Die sind dort. Diese beiden sind einmal SMRAM, die sind verschieden und der normale Speicher. Der ganze normale Speicher auf der vorhergehenden Folie. Und wenn die CPU den SMM-Modus eintritt, dann kann die CPU all diese Bereiche lesen oder beschreiben. Und danach wird das wieder deaktiviert. Es ist nicht mehr sichtbar. Und wir haben an dieser Bereich Adressräume für jede virtuale CPU. Es ist also nicht möglich, SMP-Attacken zu nutzen, weil jeder privaten Adressraum hat. Es ist also nicht möglich, dass wenn man mehrere CPUs versucht, den SMM-Modus zu bringen, es ist also nicht möglich, den anderen Adressraum oder anderen CPU zu bearbeiten. Für jede CPU ist es deaktiviert oder aktiviert hiermit. Wir müssen natürlich auch um die PCI-Geräte uns kümmern. Die benutzten für den Bassmaster-DMA, das ist im Prinzip das gleiche, wie jeder CPU sieht, ob es nicht im System-Management-Modus ist. Man kann also nicht eine Netzwerkarte oder eine Festplatte benutzen, um diesen Speicher direkt zu benutzen. Wir haben also auch das Problem, dass wir den Log-Bit-Support implementieren müssen. Das ist unser Test-Case. Die Konfiguration für unseren Gast hat eine offene Konfiguration. Das bedeutet, dass wir den SMM-Ram-Verfügung machen können, selbst wenn es nicht im SMM-Modus ist. Der erste Teil ist also, dieses Test hier prüft also, ob das Open-Bit gesetzt werden kann. Und es ist tatsächlich auch offen. Der zweite Teil prüft und setzt das Log-Bit. Und wenn man das Log-Bit auf True setzt, dann wird das Open-Bit auf False gesetzt. Und SM-Ram ist nur zum System-Management-Modus verfügbar dann. Und es wird auch das Open-Bit geflippt, sodass man es nicht wieder öffnen kann. Dieses Log-Bit wird auch die Konfigurationen sperren für T-Sack-Speicher. Das originale Q35-Chip-Set, ein physikalischer Hardware, hat da ein Bug. Da ist ein Register, welches den Speicher-Aufteilung registriert, insbesondere was vor- und nach-vier-Gigabyte registriert wird, wenn man das ganze sperrt. Es wird ein Log-Bit gesetzt, um die Konfiguration zu sperren, wo T-Sack und die Größe und das Enable-Bit sind gesperrt, aber nicht dieses Konfigurationsregister. Man kann dieses Konfigurationsregister netzen, um den Speicher, um diese Schutz wegzuschreiben und den Speicher dann doch zu benutzen. Das ist relativ einfach zu benutzen für QEModern. Wir müssen einfach nur den Speicher-Split nicht so konfigurieren, sodass das Problem nicht mehr existiert. So kann man das auch nicht mehr ausnutzen. Und wir nutzen, wir machen die Memory-Konfiguration mit Command-Lan-Switches. Und alles überall ist ganz einfach. Das nächste ist die Flasch-Sicherung, wo die ganzen Schlüssel und die Variablen gespeichert sind. Wir müssen das auch schützen. Und auf physikalischer Hardware arbeitet das so, dass wenn man schreiben möchte, wenn man das versucht, zu einem, wird es in den Device-Modus geschaltet. Und es wird auch ein System-Management Interrupt getriggert. Und der bringt das dann zurück in den Read-Only-Modus. Das ist relativ kompliziert. Und man kann, und das ist auch ein Problem für Racer-Trucken. Und es gab dafür auch schon positive Beispiele. Weil es auch physikalische Hardware ist, kann man das nicht fixen. Neue Chipset-Versionen nutzen noch viel komplizierter Protokolle, um die Races zu handhaben. Und wir haben versucht, dieses in einfacher Art und Weise zu machen. Als erstes haben wir, wir haben zwei Teile. Wir haben zuerst den Code und zweitens die Variablen. Wo die ganzen Variablen und die Schlüssel gespeichert sind. Und der Code ist normalerweise Read-Only. Firmen-Updates arbeiten in der Art und Weise, dass man sie auf dem Host macht. Firmen-Ware ist also ein ganz normales Distro-Package. Also wird das Ganze auch einfach zusammen mit QMico-Upgraded. Also mein Update dann auf die Firmen-Ware. Auf dem nächsten Power-Zyklus der virtual machine wird dann das Ganze aktualisiert. Wir haben den zweiten Teil des Flash, welches die Variablen speichert. Und wir können ganz einfach alles wegwerfen. Alles, was geschrieben wird, was nicht im Systemmanagement-Modus ist. Es ist ein Konzept, was wir von ARM ausgeliehen haben. Mit dem Secure Flack, was auf ARM benutzt wird, um Kernel Mode und User Space zu signalisieren. Oder auch als Bus Signal. Das heißt, der Flash-Chip kann sehen, wann immer der Zugriff vom Kernel oder vom User Space kommt. Und man kann auf die Art und Weise den Zugriff kontrollieren. Auf X68 wird das nicht als Bus Signal implementiert. Also können wir beides nutzen, sowohl im Concept als auch im User Space. Es ist implementiert mit Hilfe von Memo Transactions-Attributen. Obwohl das Secure-Bit gesetzt wird. Das heißt, der Secure-Chip kann dann entscheiden, ob wir diesen Zugriff zulassen können oder nicht. Das ist eine ganze Menge einfacher als auch physikalischer Hardware. Das funktioniert alles mit TSCG. Aber wir wollen es halt auch möglichst schnell ausführen, nämlich in KVM. Und jetzt schauen wir uns an, wie wir das umgesetzt haben. Wir können normalerweise nicht einfach die memory-region-Herarchie an KVM weitergeben, also in den Kernel. Das versteht das nicht. Das heißt, QEMO muss den Adressraum in eine Memory-Map zusammenfassen, was dann einfach nur eine verketterte Liste von Stots ist. Und diese Liste wird dann an KVM, das Kernelmodul gegeben. Und das Kernelmodul kennt dann halt eben das. Und diese Memory-Map wird dann von allen CPUs genutzt, also von allen Wurther-N-CPUs. Jedes Mal, wenn sich dann der Adressraum ändert, muss diese Map aktualisiert werden. Und das wird dann tatsächlich relativ teuer auf SMP-Maschinen. Deswegen haben wir denselben Ansatz gewählt wie auf TSCG-Maschinen, wo wir halt jeweils für jede CPU einen eigenen Mapping genutzt haben. So, es hat dann halt eben, ja, es klingt dann eben doch etwas anders. Das heißt, KVM hat nämlich nur eine Unterstützung für Adress-Base-IDs. Das heißt, wir können zwei Memory-Maps übergeben, nämlich einen für System-Management-Mode und eine für Nicht-System-Management-Mode. Und diese ganzen Maps werden aber wieder über alle CPUs geteilt. Das heißt, auch mehr V-CPUs machen das jetzt nicht langsamer. Wir brauchen noch ein neues IO-CTL, nämlich, wir müssen nämlich KVM irgendwie eine Möglichkeit geben, zu sagen, dass jetzt als System-Management-Interakt passieren soll. Und, ja, dann hat noch das KVM-Front-Structure im Kernel einen System-Management-Mode bekommen, sodass der QEMO weiß, ob die V-CPU gerade im SSM steht oder nicht. Das hier sind dann die Adress-Räume im KVM-Modus. Sie sehen etwas anders aus. Wir haben zwei von ihnen, um halt eben diese beiden Memory-Maps zu generieren. Eine ist der CPU-Speicher, das ist die normale Systemansicht. Wenn man also nicht im System-Management-Mode ist und für den System-Management-Mode haben wir dann eben diesen KVM-SM-Ram-Adress-Raum, der im Prinzip einfach SM-Ram ist, also ein SM-Ram-Container ziemlich ähnlich zu dem, aus dem TCG-Mode allerdings ein höherer Priorität, und dann mit niedrigerer Priorität ein alias zum normalen System haben. So, das war es also im Prinzip für KVM. Und dann müssen wir das natürlich auch irgendwie in UVMF unterstützen. Also, haben wir uns einfach gedacht, das sollte eigentlich nicht so schwer sein, weil eben der ganze Gedanke dahinterwahl, dass wir es mit SSM waren, dass wir eben den Code scheren können und wiederverwenden können. Und der SSM-Lockbox-Code befindet sich im EDK2-Repro. Aber die SMM Initialisierung und die Händler dafür nicht. Also, haben wir uns angeschaut, haben die Intel-Leute gefragt, die halt eben dieses EDK2-Repro maintainen. Und was wir zuerst bekommen haben, es war ein Hinweis auf das Quark Toolkit, das ein 32-Bit Referenzdesign von Intel ist. Und da war halt auch nur der 32-Bit Code drin, was etwas enttäuscht war. Und Laslo, ein Mitarbeiter von mir, hat einen Kollegen von mir, hat einen Bug da drin gefunden, was dann auch noch mal alles etwas dazu gehört hat. Wir hatten viele Diskussion mit Intel, auch mit den EDK2-Mentenern und seinen Quark Team und der Security Team. Das Sicherheitsproblem wurde nicht besonders gut behandelt. Mir ist kein offizieller Security-Advisor bekannt, dass dazu veröffentlicht wurde. Aber ein halbes Jahr später war dann der Code committed ins EDK2-Repro. Und zwar nicht nur im 32-Bit Code, sondern auch im 64-Bit Code, den wir dann auch bekommen haben. Da ist halt auch der X64 Erstepot mit rausgekommen, mit gefixem Code. Wir sehen halt derzeit einen kontinuierlichen Fluss an Änderungen und Erweiterung. Das ist halt nicht so, wie bei Android, dass einfach nur ein Code-Dump kommt, sondern es sieht tatsächlich ganz gut aus. Die Entwicklung passiert tatsächlich im Rebo im Offenen, also Open Source. Das Schöne ist dann, weil halt es eben auch für Open Source veröffentlicht wird, sollte man dann irgendwann in der Lage sein, sich anzuschauen, welcher Code da tatsächlich auf dem eigenen Laptop läuft. Also es ist ganz schön, dass wir im Rahmen dieser Anleitung diese Sache Open Source bekommen haben. So jetzt, mit diesen ganzen Sachen erreicht, war es eigentlich dann relativ einfach, um zu setzen, dass wir uns das ursprünglich gedacht haben. Es hat einige Versuche gebraucht, das korrekt zu bekommen, aber wir haben es dann irgendwann gemirkt bekommen. Ein Monat nachdem der Installationscode gemirkt wurde. Das heißt, wenn ihr hier mit rumspielen wollt, braucht ihr QEMO 2.5, Linux 4.4 oder neuer. Das sollte kein besonders großes Problem sein mit einer einigermaßen aktuellen Distributionen-Lipwirt-Unterstützung. Das hätte das länger gedauert, in Version 2.1.0. Das ist noch relativ neu. Es könnte also sein, dass ihr es in eurer Distribution nicht habt. EDK 2 macht nicht wirklich Releases. Man kann einfach den letzten Git Snapshot nutzen. In Rated 7 nutzen wir einen Snapshot aus der Mitte des Jahres. Und dann sieht das in der Lipwirt-Konfiguration so aus. Ihr braucht den Q35-Maschinen-Typ. Seht ihr hier? Ups, das ist ein bisschen lang. Ich mache es noch mal ein bisschen klein, damit es reinpasst. Wenn ihr nicht die Default-Firmware, also wenn ihr nicht CBIOS wollt, dann müsst ihr eben diesen Loader-Attack spezifizieren, mit dem ihr, der heißt so aus historischen Gründen, kommt aus gesetzten Zeiten. Aber wir benutzen das jetzt nur, weil wir den Red only-Mapen wollen. Secure benutzen wir für den variablen Speicher und Type-P-Flesh. Das bedeutet, dass es Flash-Speicher ist. Und dann dieses VRAM-Template. Das ist ein Template, also eine Vorlage für den variablen Speicher, in dem Fall den leeren variablen Speicher. Und das wird dann, Lipwirt wird dann halt automatisch eine Kopie davon erstellen, wo ein Valep-Lipwirt speichern und die dann weiter benutzen in Zukunft. Und natürlich braucht man bei den Features System Management Mode angeschaltet. Das ist halt standardmäßig aus, damit es auch auf älteren Versionen funktioniert. Der QEMO-Aufruf sieht dann folgendermaßen aus. Man braucht halt wieder den Q35-Maschinen-Type und man muss den System Management Mode anschalten. Die hier erstellen das Flash-Gerät. Das erste ist für die Firmware, für den Code. Das wird eben auch Fried-Only gestellt haben. Und das zweite ist für die Variablen, die wir auf Secure-Modus gestellt haben. Was wir mit diesen Configurts uns Parameter tun. Und dann eben halt die ganzen weiteren Argumente zur Konflikation von QEMO. Eine ganz schöne Sache hier bei QEMO-Unterstützung. Also bei der QEMO und der QEMO und der QEMO-Unterstützung ist, dass man QEMO Argumente einfach in die Lippwirt-Konfiguration mit reintun kann, in diesen speziellen QEMO-Tags. Man muss diesen speziellen Namespace importieren und dann kann man halt einfach das so spezifizieren. Das ist ziemlich nützlich, wenn man ein Lippwirt hat, was System Management Support nicht unterstützt, kann man das halt so reinbauen. Es wurde speziell gemacht, damit Entwickler an neuerem QEMO grabenen Entwickler kennen, was noch nicht von Lippwirt unterstützt wird. So, und das heißt, man kann dann einfach die QEMO-Kommand dann halt direkt da drin bearbeiten. Ich betreibe eine Jenkins-Instanz, die automatische Filmwehrbilds von Bilds erstellt. Das ist unter dieser Adresse. Jedes Mal, wenn etwas upstream kommetet wird, wird ein neuer Bild eingetreten. Das heißt, es wird relativ häufig geupdatet. Es ist ein einfacher Weg, die EDK2-Filmwehr zu installieren. Also, das Open-UVMF-Format. Es gibt auch noch Pakete für CBOs und Coreboot, aber für uns ist es auch noch so. Es gibt drei verschiedene Varianten. Es gibt die eine, die heißt NEED SMM. Das ist die mit System-Management-Support. System-Management-Support ist eine Compile-Time-Option. Das heißt, es ist beinahe funktioniert nicht ohne System-Management-Support. Es braucht eben auch Q35, weil ältere Versionen einen nicht ausreichenden großen T-Sack haben. Es funktioniert dann sowohl auf Q35 als auch E440FX, aber hat eben keinen Secure-Bootsupport. Es ist CSM, das heißt, mit CBS-Unterstützung kompiliert. Man kann das dann halt in der Virtual-Maschine direkt nutzen. Und wenn man damit irgendwie umspielen will oder sowas, dann kann man das benutzen. Wie ist die Uhr? Okay, wir haben genug Zeit für eine Demo. Also... Lass uns diese hier benutzen. Also, diese hier. Das ist die Secure-Boots-Konfiguration. Man kann sich das angucken, es ist deaktiviert. Ich habe die vorübersprungen, aber ich kann es in der Demo zeigen. Lass uns hier rausgehen. OVMF kommt ohne irgendwelche Schlüssel für einen Speicher. Und wie man die hinzufügt, ist es ein bisschen ISO. Das hier. Das hier. Das hier. Das hier. Das hier. Ist ein ISO-Image. Angebracht in das SCSI-CG-Grom. Das hier ist eine EV-Anwendung, die genutzt werden kann, um die Default-Schüssel hinzuzufügen. Die Schlüssel hinzufügen. Und Secure-Bootsupport aktivieren. Dann können wir neu starten. Und das ist ein ISO-Image, was Secure-Boots aktiviert, ist nicht signiert, so dass Secure-Boots das nicht erlädt. Also, nehme ich einfach dieses hier. Also, nehme ich einfach dieses hier. Also, nehme ich einfach dieses hier. Jetzt mal dieses hier beenden. Wir können sehen, Secure-Boots ist aktiviert. Und wenn man sich jetzt das hier anguckt, kann man die Zertifikate sehen, welche geladen werden. Welche von dieser, von wenn sie geladen werden. Das erste ist sein Windows-Schüssel, den Microsoft benutzt um die ganzen Windows-Betriebssysteme zu signieren. Das andere ist ein Schüssel, den Microsoft nutzt, um Sort-Party-Anwendung zu signieren. Zum Beispiel wird er benutzt um Linux. Linux-EV-Anwendung. Oder Dual-Boot-Anwendung zu nutzen. Und also PCI-Arms und stuff like that. Natürlich auch PCI-Arms und ähnliches. Und die Rated-Version von diesem ISO wird in einem eigenen Geh installiert. Lass uns das schließen. Das ist das Ende. Ich habe das nicht alles alleine gemacht. Das war ein relativ geringer Teil. Zum Beispiel die Q35 Chipset-Implementierung. Auch Baolo war daran beteiligt. Den ganzen KVM und TZG. Das ist ein KVM-Cornel-Maintainer. Und das meiste hat in drin gemacht, innerhalb von OVMF. Und das ganze Gerede mit den Interlocken. Und die Sache mit dem Source Code für die SMM-Initialisierung bei Laszlo. Der hat die meiste Arbeit gemacht am Ende. Und das ist das Ende. Das ist das Ende. Der hat die meiste Arbeit gemacht am Ende. Und das ganze geht. Die Slides sind online. Auf diesem Link. Das ist es. Irgendwelche Fragen. Wir haben 4 Mikros. Eine kurze Frage. Bin ich hochlevelig? Das funktioniert virtuell mit C-Gruppen. Ist das überhaupt nicht relevant? Ich glaube, für Container ist das überhaupt nicht relevant. Ist da irgendein Bedarf davon? Für Secureboot in diesem Environment? Nein, ich glaube, da müsste man einen komplett anderen Ansatz wählen. Ich glaube, da müsste man einen komplett anderen Ansatz wählen. Ich glaube, da müsste man einen komplett anderen Ansatz wählen. Da hat man ja keine virtuelle Maschine. Da hat man keine Firmenwelt. Wo Container laufen? Da hat man keine Firmenwelt, die in den Containern läuft. Es gibt keine Fragen aus dem Internet. Es gibt keine Fragen aus dem Internet. Wir danken nochmal für diesen tollen Vortrag. Und aus der Übersetzungskapazität.