 Hier ist Feedback über Twitter. Hersteg C3 in ausgeschrieben. Das ist nur drei, ne? Nur drei. Die Zahl. Tee. Los geht's. Sie sah, wir haben schon einen Talk about Car Hacking gehalten. Der konnte dann ein Navigationssysteme umführen. Er bricht jetzt nicht mehr in Autos ein, sondern baut ein sicheres Zeug. Für einiges davon wird man für die Armory benutzt. Die Waffenkammer, habt ihr vielleicht schon gehört. Hier ist Tamago. Ja, blankes Blech. Go Framework für RMS OC. Kann ich mich hören? Vielen Dank für die Einleitung. Danke für die Änderung, wie alt ich bin. Wir brächen immer noch Autos. Aber das ist jetzt Arbeit und nicht mehr lustig. Das Funding ist das jetzt hier, aber wir brächen immer noch Autos auf. Die Arbeiter für F-Secure, kleine Einleitung, F-Secure, kennt mich vielleicht. Es geht nur von Inverse Path. Ich bin einer der Autos in der USB Armory, der USB Waffenkammer. In der Info gesagt wurde, ob ich viel mit Hardware und in Sicherheitskritischen Systemen wie Autos, Flugzeugen, industriellen Systemen usw. Weil ich alt werde, mag ich jetzt lieber Sachen zu bauen und zu machen. Man schläft sie einfach nur kaputt zu machen. Ich glaube, das ist nicht wirklich vermeidbar, wenn du ein Informationswissenschaftsforscher bist. Anstatt einfach Sachen zu zeigen, kaputt zu sein, wird die Industrie irgendwann so gut, dass wir auch ein bisschen aufhören müssen, daran denken müssen, wie wir Sachen bauen, Hardware und Software, die nicht die Sicherheitskommunität helfen, diese Sicherheitsprobleme zu beheben. Unsere Probleme verwandeln sich halt irgendwie nie. Das sehen wir, obwohl wir jetzt fast 2020 haben. Darum müssen wir Open-Hardware bauen und wollen Automago bauen, was viel mit der USB Armory zu tun hat. Wir müssen bessere Tools rausbringen, die gut geölt sind, die ganze Zeit maintain werden und so weiter. Das ist alles wahrscheinlich, weil ich alt werde. Der USB ist ein Open-Hardware-Computer, das ein sehr sicherer Platz sein soll in so einem kleinen Ort, so ein USB-Stick. Und Automago basiert auf unseren Wünschen, eine bessere Software für dieses Gerät zu bauen, die ganze Inspiration kommt also immer durch die Reise diese Hardware zu bauen. Das ist ein sehr einfaches Szenario, das wir beim Testen von System Down-Making. Ich glaube, es ist stark an den Fakt, dass die natürliche Sprachen, wenn irgendwer von euch für eine spezifische Skatecode wollen in der Sprache, die ihr wollt, dann solltet ihr das können. Und wenn die Implantation dieser Sprache irgendwie am Grund ein Compiler generiert, der nicht schnell genug ist, ein gutes Projekt auf irgendeine Hardware zu haben, dann ist das nicht dein Problem, es sollte nicht dein Problem sein, dass du die falsche Sprache genommen hast oder so, sondern die Sprache sollte für eure Wünsche angepasst sein. Als Programmierer und Entwickler sollten wir in der idealen Welt nicht kümmern, ob der Compiler imprimiert ist oder nicht, in der idealen Welt, sondern alle Compiler gleich gut darin Maschinencode zu generieren. Gretz Signacuse machst oder in Go Python Assembly oder sowas auch immer in der idealen Welt, Star Trek Enterprise Welt sollte das im gleichen Weitcode generieren. Denn was du mit dem Code machen willst, ist dasselbe, wir leben nicht in dieser Welt, wir leben in einer echten Welt und das bedeutet, dass die Entwickler müssen Frameworks und Sprachen auswählen, die Implantation, die Implantation, die Implantation, die Implantation, die Hardware, die da supporten werden, das ist nicht ideal. Und das ist ein sehr vereinzeltes, unterschiedliches Szenario. Wir haben Sprachen, die haben nicht so hohe Zylassifikationen und das wollen wir dann einfacher machen oder weniger Geld für ausgeben und das einzige praktische und auf diesen Geräten zu programmieren, ist eine über unsichere, niedrige Level Sprachgenuss, zum Beispiel C. Wir machen Kryptografik-Token, wir machen Cryptocurrency, Geldbörsen und so weiter und sofort auf Autos, Flugzeugen und diese ganzen Appliances haben firmware, die sehr basic ist, die eigentlich von der Implantierungsseite ja nicht sicher ist und auf der anderen Seite haben wir ein Hardware mit High-Level-Spezifikationen haben. Dann müssen wir komplexe Operations- und Betriebssysteme oder Schützen, wenn wir darauf irgendwas schreiben wollen. Wenn wir Go oder Python oder so was, also Higher-Level-Sprachen geschrieben, dann schieben wir einfach die Komplexität rum. Die Komplexität oder Unsicherheit wird von uns als Programmierer weggenommen, aber überall anders in den Stack geschoben wird diesen Code laufen. Wir haben Linux-Systeme, viele Treiber, die wir vielleicht nicht haben wollen. Wir schleppen Millionen-Linien-Codes mit uns rum, die nicht wirklich nötig sind für die Aufgaben, die wir machen. Komplexität wissen wir ja, es ist ein Fehler, ein Gegner der Sicherheit. Wenn wir ein System programmieren wollen auf einer High-Level-Sprache, dann möchte ich nicht einfach die ganze Komplexität unter den Teppich schieben, und das ist davon sich direkt, dass es einfach weggeht. Wir sehen also diese zwei Szenarien. Nix-Telephone ist ideal. In diesem Fall sehen wir so eine Veränderung, eine Veränderung weg von Microcontrollern und Systeme, die ein bisschen komplexer sein müssten, und wir sehen auch sehr verbreitet, obwohl da so ein starkes OS drunter ist, sehen wir auch die Räte, Infotainment-Systeme usw., die auf sehr basischen Systemen laufen. Die brechen wir die ganze Zeit auf, weil natürlich C eine schwierige Sprache ist, mit der man Codes. Egal ob du mit C jetzt magst oder nicht, ist es einfach bewiesen, dass es sehr schwierig ist zu Produktions-Fegen-Code zu haben, den viele Entwickler sicher nehmen, weil es einfach zu anstrengend ist, das so zu machen, so viel Anstrengung braucht. Also kriegen wir es immerhin, dieses Systeme zu brechen. Wenn wir ein System auf Ship basiert und Haber bauen, wollen wir nicht diese Situationen haben. An nicht einfach schlechten C-Codes schreiben, basischen C-Codes schreiben und dann gleichzeitig High-Level-Language Anwendung auf unter komplexen Operations-Systemen laufen haben. Und unser Ziel hier ist die Angriffsoberfläche des Systems zu verringern. Wir wollen nicht Million-Lines-Code mit uns rumtragen, die unnötig sind. Wir wollen das basische Minimum haben ohne Dependenzen, ohne Abhängigkeiten ohne komplexe Operations-Systeme. Wir wollen also nicht riesen Komplexitäten mit uns rumschletten oder irgendwo verstecken. Wir wollen eine Language wie Go direkt auf diesen basischen System. Das will Tamago machen, das ist direkt inspiriert von der USB Armory. Und jetzt viele von euch kennen Go. Viele von euch denken warum nicht Rust und gucken uns gleich an. Aber was ich sagen will ist, warum nicht beides. Wir wollen, dass Leute die Wahl haben, die Language zu benutzen, die sie wollen. Wir wollen Go, darum haben wir das hier gebaut. Warum Go? Das ist erstmal ein Disclaimer. Wir gehen hier in dieses Thema, da gibt es viele Gamewords, Leute haben Gefühle, ich habe Gefühle, ihr habt Gefühle, alle haben Gefühle über Languages Sprachen, das ist kein Talk drüber, ob Sprache X besser ist als Sprache X, sondern ich sage euch nicht, dass Go besser ist als alle anderen. Ich sage nur, dass ihr glaubt, dass bestimmte Sprachen nicht so eine gute Chance haben auf Basischen Sachen zu laufen. Wir möchten das alles divers läuft und euch nicht irgendwie sagen, dass Go besser ist als Rust sondern wir wollen euch die Wahl geben und das hier ist die Wahl für Go, das gab es halt vorhin nicht. Das ist jetzt nicht größer verhältnismäßig korrekt. Das ist alles subjektiv hier. Aber wenn wir jetzt eine Wahl würden es Go langsamer als Rust natürlich, aber es einfacher bei bestimmten Grad zu lernen, Go ist ein bisschen einfacher, ein bisschen flacher als Rust. Rust ist sehr viel besser, sicher als Sie gibt es mehr Kontrolle, aber es ist auch schwer, richtig zu konzentrieren. Jetzt haben wir eine Situation, wo ich frage, wie Go sehr schnell sind und viel schneller als Python oder Ruby. Kann man echt gute Binaries bauen. Es ist ein bisschen von der Hardware abgehoben. Wenn man also Firmen machen will auf niedrigen Level, das fängt irgendwie richtig mit Go. Wir möchten das irgendwie so ein bisschen fixen, jedenfalls für Go. Jetzt, warum wir das wollen, ist es nicht das typische Setup für irgendwelche Metersysteme. Wir haben ein Bootloader, der sicher geboten ist von der Hardware auf dem Ship, der Software auf dem Ship und der Bootloader authentiziert die Prämie Sprache für einem OS, das Sie meistens benutzen und das Bootstrap dann die Prozedur für eine verschlüsselte Partition und so weiter. Vielleicht hat der Treiber kommuniziert Sachen vom Chip zu holen. Klar, so eine typische Kette von sicherer vom Rückenbruch um halt auch sicherzustellen, dass die Daten sicher sind. Normalerweise haben wir so ein Szenario, wo wir was herstellen, zum Beispiel die Geldbörse oder was auch immer Kryptofilmwerb und jetzt koden wir das in Go oder so. Wir haben sehr wenig Code Linien in Go, Standard Bibliothek für alles, TLS, Krypto wir minimalisieren die Dependentzen das ist sehr nice aber um das zu booten um das auf die USB Armory zu booten dann müssen wir ein Minux-Image rumtragen um sehr einfache Sachen damit zu machen wie z.B. Sachenentschlüsse mit dem System für Schiffzüge zu drehen, USB und dann die Anwendung zu starten. Für uns ist es also letztendlich unelegant dass wir so viel Zeit dafür verbrauchen den Code der Firma aufzuräumen und dann einen riesen Betriebssystem in unser rumster Vergleich mit dem was wir brauchen obwohl wir einfach nur ein paar Treiber brauchen wir brauchen das alles up to date halten und wir brauchen viel Platz für die Tools wir benutzen so wenig Tools hier können Busybox und so weiter aber es fühlt sich immer noch nicht richtig an das zu machen das ist zwar ein Beispiel was von der USB Armory kommt ist es aber trotzdem sehr allgemein gültig und im Prinzip funktionieren die anderen Pakete die ähnliches tun auf die gleiche Weise was wir also machen wollten ist wir wollten Go nehmen und einfach auf der Achse nach links schieben also wir wollen dieselbe Einfachheit und dieselbe Geschwindigkeit bei der Entwicklung behalten aber wir wollen auch mehr Kontrolle über die Hardware das heißt wir wollen diese rote Box nehmen und diese vielen Millionen Zahlen Code wegwerfen die wir nicht besitzen und die wir dann einfach wegwerfen können so das ist einfach die Idee von Tamago das ist kein wahnsinnig neues Konzept man nennt das üblicherweise Unicurnel oder Bibliothek Betriebssysteme das bedeutet man hat einen einzigen Raum der benutzt wird um ein Bibliothek Betriebssystem auszuführen normalerweise auf dem direkt auf dem Metall direkt auf dem Prozessor der Witz ist man kann die Angriffsoberfläche verringern dadurch und was wir damit machen ist wir verstecken die ganze Komplexität für euch den Anwendungsentwicklung und wie die üblicherweise funktionieren ist, man kriegt irgendwie eine API und man kriegt Entwicklung wie man das entwickeln muss damit man das verpacken muss damit man das ausführen kann aber was dann immer noch die Tatsache ist ist dass man eine Körnel unten drunter hat zum Beispiel BSD NetBSD FreeBSD und das macht einen Haufen Abstraktionsebenen dazwischen sodass man das nicht mehr sieht und man deployt nur seine Applikation das ist alles ganz gut und das ist das Problem nicht wirklich weil eigentlich macht das Problem schlimmer als ich jetzt umgeforscht habe für diesen Vortrag habe ich mal geguckt was es da noch alles an Projekten gibt und es war in vielen Fällen echt schwierig rauszufinden welchen Körnel sie eigentlich ausführen am Ende des Tages und die schauen immer so aus es wäre das irgendwie so ein magisches Uni-Körnel-Projekt aber die meisten von denen benutzen einfach nur ein BSD-Körnel am Ende und manche andere zum Beispiel MiniOS das ist noch in C geschrieben das ist zwar deutlich kleiner und kürzer als ein BSD aber immer noch und manche sind auch gar nicht darauf ausgelegt dass man sie direkt auf dem Blech ausführt also dadurch dass sie einfach einen Hypervisor dazwischen brauchen wie zum Beispiel Zen was wir auch nicht machen wollen das heißt bei den meisten Uni-Körnel-Projekten die im Moment existieren die lassen sich nicht wirklich für das Einsetzen was wir machen wollen nämlich C rauswerfen im Prinzip wollen wir C komplett loswerden zumindest so lange wir unsere Firmen laufen lassen wollen wir keinerlei C-Code mehr dabei ausführen egal wie viel man da wegabstrahiert wenn man irgendwie immer noch den Hypervisor oder den Körnel dabei hat hat man halt Code in C geschrieben müssen den wir dann ausführen also ist das das nicht das was wir haben wollen am Ende des Tages und das andere Problem was wir haben ist wenn man sich von der Sicherheit das ganze an sieht die meisten Anwendungsfälle wollen relativ generische Anwendungen unterstützen einfach individuell geschrieben vom Entwickler das heißt man braucht relativ generell geschriebene Betriebssysteme das Problem ist wenn man verschiedene Anwendungen hat mit in verschiedenen Sicherheitsleveln und dann auch noch das ganze in einer unsicheren Sprache WC geschrieben dann will man dann will man verschiedene Dinge Features wie Adressraum Verwirfelung oder andere Sachen die einfach reingeschrieben wurden die diese Systeme unterstützen das heißt aber in dem Moment wo wir das einen anderen Ansatz erfahren und zwar ein Unicornl direkt auf den Blech ausführen wollen können wir uns davon verabschieden und das ganze vereinfachen das heißt wir haben keine Idee also wir wollen nicht in die Cloud und wir wollen Go verwenden und wir wollten Go echte Chance geben dass wir das inkriegen weil wir glauben dass es eine relativ flacher Lernkurve hat und es hat auch noch andere Vorzüge wie zum Beispiel höhere Produktiv und eben zum Beispiel auch eine richtig mächtige kryptografische Bibliothek und Rust hat ja auch schon gezeigt dass es geht aber Go hatte diese Chance noch nicht das wollen wir noch machen weil wir glauben daran dass es geht also was wir jetzt am Ende des Tages schaffen wollen ist es kommt auch drauf an wie man es macht nicht nur dass man es kann jeder kann irgendwie wenn man genug Arbeit reinsteckt kann man Go immer irgendwie direkt auf den Blech ausführen es geht auch darum das muss vertrauenswürdig sein das heißt Tamago ist die Idee wir wollen den einfachsten Weg finden wie wir den Go-Compiler patchen können sodass wir minimal intrusiv arbeiten also möglichst wenig ändern möglichst sauber arbeiten so normalerweise ist es so man gibt eine Variable an der es Go ist da haben wir ein extra Ziel erzeugt mit unser minimal patch der heißt dann Tamago das ist die eine Hälfte von Tamago dann gibt es noch Pakete die man halt braucht für die individuellen Bord die man unterstützt also im Moment haben wir natürlich Unterstützung für den USB Armory Satz an Chips das ist ein Mitglied der NXP eMX6 Familie unser Ziel war es dass wir Sicherheitsanwendungen dafür entwickeln unter anderem mit verschlüsselten Bootloadern und verschlüsselten Partizionen und es gibt jetzt auch verschiedene andere Ansätze wie wir das in Go ähnliche Ziele verfolgt werden die Gründen waren die nicht dass das hier wollten also da gibt es zwei Projekte die nicht mehr unterstützt werden das erste ist Biscuit das ist ein Go-Körnel direkt in Go geschrieben der nicht Go Software auch unterstützen sollte der hätte im Prinzip USB Compatible Interface gehabt es ist ein Haufen Komplexität dahinter und es ist auch nicht mehr unterstützt sie haben zum Beispiel den existierenden Linux-Isolinux-Support reingeschrieben der dann auch wieder nicht unterstützt ist dann gibt es noch ein anderes Projekt das heißt Gert das ist auch nicht unterstützt ähm die Idee hier ist äh das ist auch wieder ein einfach nur ein Biscuit Abkömmling und man hat die gleichen Probleme auch zum Beispiel dass wieder Isolinux mit dabei ist dann gibt es noch ein interessantes OS das ist relativ ähnlich wie Tamago und das aber nicht direkt auf den Blech läuft sondern auf dem Zen Hypervisor und wenn ihr euch jetzt ein bisschen auskennt im Ökosystem dann kennt ihr wahrscheinlich TinyGo zwar relativ interessant aber es hat ganz andere Ziele als hier weil es eine eine komplette neue Implementierung des Go-Compilers das hat auch andere Ziele das ist ähm richtige große Chips und nicht System-On-Chips äh als als Deployment-Ziel hat und dann gibt es noch was ganz Neues das ist erst ein paar Tage alt das heißt Embedded Go das zielt auch auf Embedded Controller ab und das auch Compiler Support dazu baut aber es nimmt Arm Fump Systeme als Ziel was auch wieder ein bisschen anders ist als das was wir machen aber wir werden es im Auge behalten weil es relativ interessant und es geht halt auch in eine ähnliche Richtung also alle diese Projekte je unabhängig davon ob sie jetzt unterstützt sind oder irgendwie kompliziert sind aber sie haben uns alle geholfen das zu verbessern was wir eigentlich machen wollen um jetzt bei unserem Projekt anzukommen unser Ansatz war nicht so sehr zu verstehen ob es geht weil das war uns klar dass es geht, es geht uns darum kann man das alles schaffen ohne dass man irgendwie den Compiler unrein macht oder einfach unsauberer Änderungen durchführen muss dazu die das Ganze weniger wartbar machen ich arbeite halt in der IT Security und das ist wirklich eine neue Anwendungsfall für uns wir haben normalerweise nicht so viel zu tun mit irgendwie Compilern und mit Sprachendesign aber wir sehen wir haben, wir sehen einfach dass es so viele Unicorn-Projekte gibt die einfach alle sinnvoll werden die aber niemals in der Produktion landen das sind Leute die richtig Leidenschaft dafür haben und die auch die einfach raus schieben wollen aber das ist nicht unser Ziel was wir machen wollen ist wir wollen es absolut minimal durchziehen es soll sauber sein, es soll vertrauenswürdig sein damit es die Leute dann auch wirklich verwenden also war unser Ziel dass wir den Compiler in der minimalen Weise patchen und nur auf die Weise wie wir als IT-Sicherheitsexperten sagen können wir trauen wir, das ist okay das können wir verantworten, dass wir das machen deswegen haben wir uns auch noch zu Nebenziele gesetzt wir müssen zum Beispiel auch den gleichen Stil des Coats einhalten damit es für die Leute wartbar ist damit es alles übergeben werden kann und dass die Leute das auch warten können wir haben das so entworfen mit dem Ziel dass wir das immer irgendwann geben können und was am Ende unser Ergebnis waren, waren nur ungefähr 3000 Zeilen Code die neu waren oder geändert wurden wir hatten relativ starken Fokus darauf, dass wir Code wieder verwenden von anderen Architekturen und unser letztes Ziel war im Prinzip einfach einen Import zu haben den man in einem Go-Projekt macht dass wir das relativ simpel verwenden können wenn du die Hardware nicht benutzt da musst du auch nichts darüber wissen es sollte keine Leihnachteile mit sich bringen also keine Run Time Dependencies die du nicht brauchst und nebenbei brauchen wir natürlich Unterstützung für relativ breiten Unterstützung für verschiedene Socks das wir kriegen dadurch dass wir den Compiler weiter verwenden relativ nette Features wie zum Beispiel dass man reproduzierbare Builds bekommt das ist natürlich für uns als IT-Sack-Experten wichtig so wie sehen jetzt unsere Änderungen aus also wir haben Glucode also Sachen die einfach zu einem Interface bilden die das zusammen e-kleben das sind nur 340 Zeilen im Prinzip haben wir nur das neue Ziel Tamago zugefügt und das hat sich aber relativ viele Dateien berührt wir mussten überall kleine Änderungen machen um einfach das neue Ziel zuzufügen das sind einfach die die Änderungen die wir brauchen damit wir das haben so und jetzt geht es darum dass wir Support für die eigentliche Run Time kriegen was wir gemacht haben ist wir haben ein Code der schon in Go im Compiler waren genommen und den einfach wiederverwendet wir nennen es den Go Frankenstein weil es ist ein Monster aber vielleicht ist es die falsche Analogie weil es ist weniger hässlicher als es aus als erst mal klingt was wir gemacht haben wir wollten die Run Time direkt auf den Blech laufen lassen deswegen da haben wir keine Break System Call deswegen müssen wir nur einen Pointer der den Speicher verwaltet umsetzen und dann sind wir schon fertig für das Locking das ist das Locking verwenden wir 1 zu 1 aus dem WebAssembly Code den können wir einfach nehmen wie er ist das gute daran ist es gibt 3 Funktionen die sich in das externe Betriebssystem hängen und das werden wir auch verwenden um irgendwie das zu implementieren und es gibt uns aber eine ganz saubere Fläche zwischen dem was auf der Betriebssystem Seite läuft und dem was wir im Go Code haben so dass wir weil es wirklich definierte Eintrittspunkte gibt die sauber definiert sind und dann haben wir noch ein Dateisystem was im Speicher lebt das wir auch einfach weiter verwenden was wir noch machen müssen ist wir müssen noch EMMC und VFAT dazu fügen aber das ist einfach und das ist auch wahrscheinlich mehr das ist schon der Großteil von allem was wir gemacht haben das ist der größte Teil unserer Code-Änderungen und das liegt einfach daran dass auf der Art und Weise wie der die Quellcode vom Compiler aufgesetzt ist mussten wir nur ein paar Ordner kopieren und im Prinzip war es das dann schon und dann haben wir noch ein bisschen neuen Code das sind ungefähr 600 Zeilen in 12. Teilen das sind die Funktionalitäten die wir nur für die Architektur bereitstellen müssen und die machen zum Beispiel Initialisierung für den Armcore das ist ziemlich standard in jedem Betriebssystem also auch im Bootloader oder so wir müssen einfach den Hieb zum Beispiel aufsetzen und das sind auch wieder Hux drin damit das Board sehen kann wie viel Speicher hat das und wie kann er das zugreifen und was für uns relativ überraschend war ist dass die Go Runtime fast komplett eh sowieso schon alleine steht es hat fast keine Abhängigkeiten die man auch auflösen müsste oder die man auch porten müsste und das war quasi alles was sie tun mussten und das ist unser Speicher-Layout da lebt das Ding im Memory Hiebstack das lebt hier im Vector-Table und das ist alles relativ Standard Go Runtime Unterstützung gibt es drei Komponenten wir haben die Unterstützung Nego Runtime das ist ein Beispiel was passiert in os domago.gov wir haben ein paar Funktionen die definiert werden müssen wir tun da Informationen rein für die verschiedenen Hardwares und Boards und die Peripherals haben eine generische Funktion für Hardware eine für Printen auf der Konsole eine für Random Zufall, Starten und die Runtime möchte, dass das hier provided wird das gleiche ist für den Offset für RAM, was ist der Offset was ist die Größe und das Dresd davon in diesem Ding ist die Architektur noch nicht so richtig spezifisch für ein Board einfach ARM Initialisierung und das ist die Go Compiler Modifizierung und dann haben wir hier das System on Chip Paket, das ist sehr einfach das Einzige was es uns gibt das ist Ux mit der Laufzeit wo das Memory anfängt im Stack und das ist was die Größe des RAM die speichert es selber für alle Ships aber wenn es verschiedene Boards hat können es vielleicht mehr RAM haben hier zum Beispiel in einem USB Armory Paket okay, sagen wir okay ich möchte, dass alles auf der Konsole gedruckt wird und das für die USB Armory ist eigentlich schon der zweite Serial Port das gehört also in die USB Armory Paket das heißt, dass wir ohne wenigen Modifizierung in der Go Runtime das mit System auf Chip spezifischen Sachen zu tun hat und jede Information die was wir mit dem Board zu tun haben im Board Support Paket hier zum Beispiel USB Armory das ist das saubere Weg, wenn man das macht anderes Beispiel hier haben wir Timer definieren Definition Go Runtime Go Needs To Get also Go muss hier Ticks kriegen und wissen wie spiel es ist hier gibt es verschiedene Timer für die Armory das wird von der Architektur rausgegeben und hier ist viel was Go auch schon macht da müssen wir gar nicht selber machen das wird schon akzeptiert das ist was Effizienteste um mit Slow Level Sachen wie Timer zu funktionieren und Fuss zu kriegen das ist der Start Code den wir da brauchen, da brauchen wir nicht so viel das ist ein anderes Beispiel wie wir entwickeln wir sagen, dass das Code langsam läuft, das ist elevatet ok, wir warten mal kurz wir müssen den Clock Geschwindigkeit ändern und von 400 auf 9 Megahertz müssen wir das ein bisschen selber machen weil der Butler oder die Frequenz nicht erlaubt und im Go haben wir in unserem Package ein System und Chip Paket haben wir die Frequenzen geändert und so sieht der Treiber aus in Go wir haben unsere Funktion für Register PLL Register wir haben 2 Bits auf 0 gesetzt in diesem Offset das ist ungefähr was du uns sehen finden würdest aber einfach mit Go wir warten, dass unser Wert 0 wird hier kommt Bypass rausgeholt wir setzen den Devise und so weiter ihr könnt Treiber in Go schreiben das Interessante ist wenn man memory-sichere Sprachen benutzt direkt auf den Blech musst du was machen, was nicht safe ist hast du sogar ein Keyword dafür in Go und anderen High Level Sprachen hast du dann das Keyword an Safe und dann kann man nach den ganzen potentiellen gefährlichen Sachen im Code angucken du kannst einfach an Safe suchen all diese Teile in der Arithmetic angucken musst du für Treiber nicht machen aber es ist sehr einfach zu identifizieren im Code und ich finde das sehr cool über eine High Level Sprache wie Go die Go Runtime macht wir benutzen Cisco sehr direkt für Funktionen das war eins unserer Hauptaugenmerke können wir das machen in der Runtime und wir brauchen eigentlich nur write und das ist das was dann braucht es um mit der Print Funktion zu verbinden und wir benutzen das um Konsole zu drucken das ist das einzige was du eigentlich brauchst auf barematch und direkt am Prozessor wenn du standard Output schreiben willst auf diesen Geräten habt keinen Bildschirm, keine Konsole das machen wir da im Bordpaket wenn jemand da was anderes machen will das ist nämlich außerhalb des Compilers könnt ihr dann die hier die PrintK Methode nehmen die ihr wollt am Ende sieht es dann so aus wir haben normalerweise deine Go Runtime unter dem User Space in einem komplexen Betriebssystem im Kernelspace können wir es dann suchen nach Drive 1 wenn die Peripherals reden usw. in Tamago haben wir den Package direkt in der Runtime das System auf dem Ship und das USB Package sind in den Treiber mit drin und dann gibt es ein System Call ist einfach nur verbunden mit dem Treiber Support im Go Package Paket und das alles in Go wenn wir die Vanilla Go Runtime benutzen die einfache Go Runtime dann gibt es die Runtime Unterstützung und die Murta-Margo und das ist die Veränderung wir reduzieren dramatisch wie viele Zahlen Kurve brauchen in diesem Setup das einzige der Bootloader der haut nach dem Boot ab wir arbeiten aber auch dran den zu ersetzen aber es gibt kein C kein bisschen und wenn wir dann dieses Ding entwickeln, bilden und zum Laufen bekommen du importierst einfach das Boot Package das ist einzig was du brauchst wenn du nun den Treiber spezifisch benutzt wenn du ein Treiber benutzen willst dann musst du es auch importieren in den Go aber für die einfachen Sachen ist das einzig was du brauchst kompiliert ihr das mit GoBuild mit ein paar klein Flags als Ausnahmen das hat was mit dem Board zu tun das zeigt wo wir das Text-Signal in unserer Anwendung haben gibt ihr diesen Befehl einen oder dann benutzt ihr einfach GoBuild und Tomago funktioniert einfach mit der Go Runtime und dann ladet ihr einfach den Elf ihr braucht kein Bootloader ihr benutzt das einfach wie ein Kernel also wir haben Treiber eingebaut sichere Treiber um uns selbst zu beweisen das was man benutzen kann das war sehr wichtig für den Prozess das da gibt es ein paar Security Treiber einem X6 und dieses Element erlaubt uns zu verschlüsseln zu entschlüsseln der Key wird in der ersten Start des Keys benutzt ihr könnt ihn nicht lesen, ihr könnt ihn nur benutzen und der Treiber dafür nimmt so ungefähr 240 Sign Code das ist 10 mal so wenig wie bei C hierfür und wenn ihr dieses Paket ladet dann braucht ihr den Drive Key und dann wird aus der Hardware dann dieser Key hergestellt das Schöne ist dass ihr Strukturen benutzen kann Ingo sodass sie mit C Kompatibel sind in bisschen Anstrengung und dann kann Daten allokiert werden zugewiesen werden haben wir diese Struktur hier Pointer und da funktioniert es einfach hier unten schreiben wir die Adresse für unsere Go Struktur zum Register zum Hardware Register und dann tut es einfach seine Arbeit wir haben den Treiber für den Zufallsnummern-Generator geändert es wird auf dem Chip gebaut das ist sehr praktisch für den ersten Boot weil diese Hardware keine Batterie hat und keine Uhr und dann brauchst du einfach nur so ein klein Seat und der wird hier benutzt, das sind 150 Zahlen Treiber hierfür wir haben das mit der Crypto Run Funktion von Go verbunden wir benutzen einfach Go und Crypto Run kommt einfach hier raus dann haben wir ein USB-Treiber geschrieben was sehr anstrengend ist kann ich euch sagen also könnt ihr eure Lebensziele in Frage stellen bis zu 40 und schreibst ein USB-Treiber aber aber Go hat hier sehr geholfen mich glücklich zu halten weil ich Go benutzen konnte ich kann diese Sachen benutzen wie ich will der gab es ein kleines Memory-Problem aber naja, kleines mit Go schreibst es gibt es nur ein paar Aspekte über die du gucken musst die sind ein bisschen merkwürdig für Go-Programmiere weil die malerweise nichts damit zu tun haben aber du brauchst Alleinst-Strackscher weil die meisten Hardware Analyne Point hast du nicht akzeptiert, da brauchen wir kleine für und du musst den Analyne Buffer wieder rum tragen um den Alignment Buffer zu unterstützen, das ist das Einzige wo ihr euch wirklich drum kümmern müsst wir haben einen vollständigen Treiber für jeden Treiber den wir machen jedes mal wenn es die Hardware angefasst hat dann ist da der Pager-Nummer und der Name unter Sektion wenn ihr euch den Code vom Linux-Körnern anguckt da sind so viele komische Dinge drin wenn ihr einfach nur einen Kommentar auf der richtigen Seite wer dann hätte man sich da Stunden von Arbeit gespart wenn ihr da lernen wollt haben wir auch alles hier mit reingetan und ich finde das fehlt viel in vielen Körnern als ich den USB Steak hatte die Treiber hatte war es ganz einfach der halbe Code ist den Descriptor zu finden und wir haben die 2 Funktionen tun das zusammen mit Google-Net Stack das ist ein sehr cooles vollständiges Go-Ding von Google das tun wir da einfach rein und das zeige ich euch eine Demo wenn es dann funktioniert auf der linken Seite zeige ich den USB Armory-Tipp mit Tamago das ist Tamago wie es läuft und was wir hier gemacht haben der Bootloader ist direkt in Go gebooted dann hat es hier einen Selbsttest von dem Zuppertestandgenerator dann erinnern wir den die Geschwindigkeit des Prozessors dann haben wir eine Datei in den Schweichern gelesen wir haben die Timer aufgesetzt dann schläft er für 100 Millisekunden dann haben wir ein paar Zuppertestanden generiert dann haben wir ECD SCA das ist die Natur in generiert dann haben wir um für 1,5 Gigabyte Speicher alokiert um den Garbage-Collector zu testen und dann haben wir das USB-Modul gestartet und wenn ich jetzt mein anderes USB Armory anstecke ich habe zwei miteinander verbunden das ist ziemlich Meter das heißt jetzt wird dann der Link evaluiert dann sieht sofort, dass es traffic drüber geht wenn ich mich jetzt auf meine andere USB Armory verbinde das ist einfach nur ein UDP Echo Server ich kann direkt den Speicher debaggen und ich kann sogar das Spiel hier starten ich streame Star Wars in ASCII und wenn ihr glaubt es sollte schneller laufen und flüssiger dann ist das Problem nicht Armory, sondern das Problem ist mindestens, dass es hier die Fensteraktualisierung nicht sauber aktualisiert und was ihr hier seht ist einfach TCP IP Handling das ganze Handling der Netzwerkspakete nichts davon hat irgendwas mit C zu tun es gibt keine einzige C-Zeile da drin das ist alles Go und ganz minimal Assemble und ich finde, das ist ziemlich beeindruckend so, jetzt schauen wir uns die Performance an mal gucken, ob der Film beendet ist wie erwartet die Geschwindigkeit ist grob dieselbe also wenn man dieselbe Anwendung unter Linux und unter Tamagut startet dann kommt es selber raus hier habt ihr ein paar Zahlen, die wir da dran hingegen haben die Zahlen sind relativ identisch und wenn wir drüber nachdenken es sollte entweder gleich schnell sein oder schneller, da wir weniger Overhead haben es gibt ein paar Einschränkungen leider, ein paar von denen wollen wir noch angehen also die Hardware auf der wir hier laufen hat nur einen Thread das heißt wenn ihr ein Loop habt, der immer wieder läuft und ihr ausbrechen müsst ihr kommt im Moment nicht raus das ist eine ziemliche Einschränkung ihr könnt es vermeiden indem ihr zum Beispiel gelegentlich den Scheduler aufruft und das solltet ihr in der realen Arbeit sowieso nicht machen wir müssen auch noch Dateisysteme im Storage implementieren wenn wir Bibliotheken importieren dann braucht ihr immer noch ein Package ihr könnt C theoretisch einbinden aber warum solltet ihr es tun aber ihr könnt es es ist alles Freestanding es gab noch bis auf ein paar kleine Überraschungen waren wir selber überrascht, wie einfach es war das ganze entsorgen zu kriegen und was wir jetzt jetzt könnt ihr im Prinzip machen, was ihr wollt alles Kryptowallets Authentifizierungstokens Dongles was wir gelernt haben ist wir können die Komplexität total verringern und nicht einfach nur woanders hinschieben wir haben C komplett ersetzt es ist wir haben geschafft, dass Goh tatsächlich jetzt mal eine Chance hat auf dem Metall direkt laufen zu können ich möchte all diesen Leuten auf der Folie danken, die beigetragen haben im Projekt und jetzt habe ich noch zwei Minuten für Fragen das war also das war die Übersetzung von dem Talk gemacht von Sireen Sange und Kaste wenn ihr uns Feedback geben wollt an an den Hashtag CPT und wir freuen euch von uns zu hören jetzt haben wir eine Frage aus dem Internet und es geht irgendwie um Sachen auf Bermetl, ob es da Probleme gibt und er sagt nein auf dem Metall, wenn ihr es einfach ausschalten wollt dann könnt ihr die Garage Collection ausschalten könnt ihr es auf einer sehr spezifischen Zeit rennen lassen wenn die Gaffikation nicht so lang geläuft dann könnt ihr es auch einfach nicht laufen lassen und das machen wir eigentlich für die Sache, die wir machen müssen die steuern wir eigentlich nie in Probleme die Performance und das Verhalten ist nicht dasselbe wie auf normalen Go Sachen auf normalen OS da gibt es keine Unterschiede was anderes, vielen Dank die nächste und letzte Frage ist eignet sich Tamago für Echtzeitanwendungen und wenn ja, wie sehr ich glaube, dass wenn wir die Garage Collection ausschalten kann das funktionieren ich bin kein großer Fan von Echtzeit Betriebssystem immer wenn Leute diese Sachen benutzen die so viele Bugs dass der Echtzeit Punkt eh nicht so gut funktioniert und dann haben wir es auch nicht so richtig gebraucht aber natürlich gibt es auch so ein paar Sachen wie zum Beispiel in Finanz, wo es wirklich braucht wenn ihr Zeit dafür habt, dann gibt es ja bestimmt eine bessere Lenkensprache für aber jetzt will ich das sagen wenn ihr die Garage Collection ausschaltet kann das bestimmt funktionieren weil das Resultat halt sehr vorhersagbar ist Danke für das Projekt drei kleine Fragen zunächst schaut ihr üblicherweise auch auf die Assembly die ihr erhaltet die zweite Frage ist Goers bekannt für Fuzzing habt ihr auch Fuzzing von euren Applikationen auf der Plattform gemacht und das letzte ist habt ihr irgendeine Fehler in der Valentine gefunden beim Porten ja, wir haben uns die Assembly angeguckt wir haben den Goers Sampler benutzt die Generations also die Herstellung ist so ganz normal wie auf dem Arm mitgehoben nur dass es halt auf dem Bear Metal ist auf dem Prozessor und fassen wir da nichts an wir fassen den Goers Sampler nicht an die zweite Frage Fuzzing wir wollen USB Fuzzen wir wollen einen Low Level USB Fuzzer bauen für den Host wir versuchen auch zu versuchen wie wir extern GoFuzz hierfür benutzen, da denken wir dran drüber nach und habt ihr Bugs gefunden? ja und wenn ihr dieses Slide hier ist ein spannender Go-Bug hier unten über die Garbage Collection da gibt es zumindest eines merkwürdiges Ding aber wir arbeiten dran und das Leute sind da sehr hilfreich und das nix was irgendwie die Show völlig gestoppt haben wir haben noch eine Frage aus dem Internet ja drei weitere Fragen haben wir dafür noch Zeit? dann nehmen wir mal nimm mal die einfachste wie günstig wäre Tamago zu benutzen für andere Microcontrollers für Microcontrollers ist einfach TinyGo der Fußabdruck für den Standard Go Compiler sehr groß also nimmst du TinyGo für das artiges Projekt guten Grund dass es das gibt für Microcontroller nimmst du TinyGo für System of Ships nimmst du Tamago das ist dann der Unterschied nächste Frage Vielen Dank für den Vertrag und für die Arbeit Würde die auch andere Ziele unterstützen z.B. den Armory MK1 oder ja, das machen wir wir unterstützen Armory MK1 und den auch Raspberry Pi Zero dass wir darauf eigentlich schon funktionieren und ich finde es ist sehr wichtig anderen Projekten die Chance zu geben und es ist eigentlich auch sehr einfach andere Hardware damit zu unterstützen das sind nur ein paar Tage Arbeit definitiv pull requests sind immer willkommen zurück zum 76 Signal Angel kann man das hier auch auf anderen Arm Cortex Prozessoren laufen lassen oder kann es benutzen, ausführen auf jedem System auf einem Chip SOC SOC das Architektur Unterstützung hat in der Runtime es ist mir eigentlich sehr einfach auf jeder Arm V7 System so ein Chip laufen zu lassen und kann man auch sehr einfach machen also wie gesagt was man dafür braucht ist es sehr einfach auf anderer Plattform zu porten so lange wir über SOCs reden sollte da eigentlich relativ einfach zu machen sein danke für die Antwort ich habe mehr Fragen würde Tamago auch auf dem Armory MK1 laufen ja definitiv wir wollen dafür sagen, dass diesen Support sehr bald gibt ein sehr interessierter nur-C Anwender was ist es an Break Register Maps und wie löst du das auf dem es funktioniert sehr gut wir nehmen GDP wir benutzen Breakpoints wie bei jeder anderen Application sonst wären wir erfrugt geworden ok, next up Microphone Number 2 please du hast erwähnt, dass du Dateisystemen Unterstützung bekommst ihr benutzt ihr wollt 4FAT benutzen es gibt eine Reingo-Implementierung dafür wenn ihr die noch nicht kennt ich glaube es ist das die Fusion Implementation haben eine Ah, die Fuse Implementierung es gibt eine Fluss nur User Space Implementierung von FAT ja, da gibt es ein paar Implementationen schon draußen sind, Gert hat das schon und wir werden versuchen das auch zu kriegen anzubauen das sollte auch drüber als sein wir benutzen FAT, weil das einfach und schnell ist braucht ihr nicht fancy, Scheiß Microphone Number 1 please Danke für den Vortrag habt ihr schon mit Abstream geredet darüber ist in die Mainland zu kriegen ja, da arbeiten wir dran wir sind da sehr nervös bei weil wir wollen, dass alles sehr sauber läuft aber wir wollen dem die beste Chance geben, das kann wir haben Kontakte bei Abstream und das wurde von einfach an so kodiert um es sauber, nice Respektabel zu haben das wollen wir, ich will den Confiler nicht maintain ich will eigentlich nur die Treiber maintain wir versuchen sehr das in einen Zustand zu kriegen wo man das abstream schicken kann habt ihr da eine Timeline für? Nein aber ich hoffe Ende nächsten Jahres wird es heiss es dann immer noch Tamago und warum heiss es so also heiss Tamago, weil Tamago Eie heiss auf japanisch und Go läuft in ihrer eigenen Shell auf dem Metall warum Tamago und eigentlich außerdem Tamagotschi danke, das ist der einzige Grund warum wir das machen erst wenn wir das Name ausgedacht haben dann haben wir gesagt, oh was können wir damit machen ja fragen wir das im Internet? Nein ich glaube wir haben hier noch eine Frage beim Miko1 heutzutage haben im embedded system immer noch Bildschirmen wie es ist bei euch ja, die USB Armory hat keinen Bildschirm das war unser Fokus nicht aber warum könnte man da keinen Videotreiber mit bauen wird vielleicht nicht ganz so schnell sein wie es kann natürlich machen, so schlaube es kann es natürlich funktionieren aber erstmal war es nicht unser Fokus unser Fokus ist klügere Smart Cards zu haben Tokens wir haben Bluetooth drauf USB erst mal wenn du eine UI dafür brauchst haben wir dann eine App für Networking aber ja vielleicht in der Zukunft, wer weiß gibt es noch eine Frage? ich schätze nein gut, dann sind wir fertig vielen Dank Andrea damit auch nochmal das Ende der Übersetzung