OP-TEE Using TrustZone to Protect Our Own Secrets

Am dritten Tag der ELC-E hatte mein Kollege Marc Kleine-Budde die zweite Gelegenheit, über OP-TEE und die sichere Speicherung in der Trustzone zu berichten. Auch diesmal war der Saal gut gefüllt, so dass sich die Wiederholung des Vortrags gelohnt hat.

Das "Trusted Execution Environment" (TEE) ist eine kleine, isolierte Umgebung für sensitiven Code+Daten. Dabei soll im TEE nur wenig Code laufen, die Hauptfunktionalität des Systems übernimmt weiterhin das "normale" Linux. Auf ARM kann ein TEE mit Hilfe der Trustzone realisiert werden, d.h. der Code läuft zwar auf dem gleichen Prozessor, aber in einer hardwareseitig abgesicherten Betriebsart, der "Secure World". Der einzige Weg von der Normal World in die Secure World geht über den Secure Monitor.

Die Hardware stellt dabei sicher, dass z.B. auf bestimmten Speicher nur in der Secure World zugegriffen werden kann. Ebenso kann auf bestimmte Register nur in der Secure World zugegriffen werden. Auf ARMv7 wird der Secure Monitor in OP-TEE implementiert, bei ARMv8 ist er Teil der Trusted Firmware. Beim Booten geht das System zunächst in den Secure State.

OP-TEE wurde zunächst proprietär implementiert und in 2015 unter der BSD Lizenz freigegeben. Seit 4.12 ist die Kernel-Seite, die Global Platform API, in Mainline, zur Zeit existieren ca. 20 Portierungen. Das OP-TEE Mini-Betriebssystem selbst besteht aus dem TEE Core, einer internen API und den Trusted Apps.

Auf i.MX6 wird der Bootvorgang mittels HABv4 abgesichert, OP-TEE wird in den Bootloader (in unserem Fall barebox) integriert und im Bootablauf ausgeführt. Barebox prüft dann die Signatur des Kernels (FIT-Image) und startet den Rest des Systems. Der OP-TEE Code läuft dann während der Lebensdauer des Systems weiter und wird im Fall eines Secure Monitor Calls angesprungen. Die bisherigen Erkenntnisse wurden im Rahmen eines Prototyps auf der Pengutronix TechWeek 2017 gewonnen; für die Zukunft wäre es hilfreich, wenn OP-TEE an die Key Storage API in Linux angebunden würde, damit man die Trustzone zum sicheren Speichern von Keys nutzen kann.

In der Diskussion wurde auf verschiedene Sicherheitsprobleme hingewiesen; es stellt sich heraus, dass Security komplex ist und es keine Garantien gibt. Allgemein wird begrüßt, wenn mehr Leute OP-TEE benutzen und die Codebase damit mehr Testing, Fuzzing usw. bekommt.

Stable Device Tree ABI - It's Possible

Nach der Mittagspause berichtete mein Kollege Lucas Stach über Maßnahmen, die ABI Stabilität von Open Firmware Devicetrees sicherzustellen. Eine Motivation für das Thema ist, dass wir bei Pengutronix Embedded Linux Systeme basierend auf dem Mainline Kernel entwickeln und dabei eine offensive Upstream-Strategie verfolgen; das bedeutet, dass produktive Systeme über lange Zeit mit neuen Kerneln ausgestattet werden.

Während der Kernel schon lange seine Initialisierung aus dem Devicetree vornimmt, greifen zunehmend auch Bootloader (barebox, U-Boot) oder Secure World Firmware auf die Informationen aus dem Devicetree zu. Einige Devicetree Properties sind gut eingeführt (z.B. Memory Nodes), aber es gibt diverse Peripheriegeräte, für die sich die Bindings über die Zeit ändern müssen. Insofern ist es kein gangbarer Weg, davon auszugehen, dass sich die Definition des Devicetrees über lange Zeiträume überhaupt nicht ändert.

Die Erkenntnisse, die vorgestellt wurden, stammen aus der Maintenance der i.MX Plattform und basieren auf den Erfahrungen, die dort in den letzten Jahren gemacht wurden. Der erste Schritt zur Definition eines stabilen Bindings ist der Blick ins Datenblatt einer Komponente: Alle Hardware-Eigenschaften müssen im Binding beschrieben werden - speziell nicht nur die, die im eigenen Design benutzt werden. Dann ist es wichtig, dass die verpflichtenden Compatibles von Tag eins an stabil gehalten werden müssen - man kann sie später nicht mehr ändern. Wenn man mit neuen Hardware-Blocks zu tun hat, sollte man neue Compatibles nutzen: Beispielsweise hat der SPI Core auf dem MX6 ULL das Compatible "fsl,imx6ul-ecspi, fsl,imx51-ecspi". Der Treiber schaut nur auf den letzten Teil, kann aber im Fall von Abweichungen anhand des ersten herausfinden, dass es sich um neuere Hardware handelt. Sollten tatsächlich Modifikationen notwendig werden, sollte man diese im Kernel und nicht im Devicetree vornehmen.

Als Fazit hat sich herausgestellt, dass eigentlich nur relativ wenige Regeln zu befolgen sind, um eine stabile Devicetree ABI zu realisieren. Die Diskussion war engagiert und zeigte, dass das das Thema komplex ist.

swupdate

Stefano Babic berichtete in meinem nächsten Vortrag über das swupdate Projekt; ich fand es interessant, zu sehen, wie andere Entwickler die Herausforderungen angehen, die wir bei Pengutronix mit RAUC umsetzen.

Zu Beginn folgte eine Einführung zu Update-Usecases, vom USB Stick bis zu Netzwerk-basierten Updates. swupdate kann ebenso wie RAUC hawkBit als Updateserver benutzen. Ebenfalls möglich ist es, ein sicheres Fallback auf ein immer vorhandenes System zu machen. Auch andere Anforderungen wie Atomarität oder das ausschließliche Ausrollen von getesteten Firmwaren sind letztlich für jedes Update-System gleich.

swupdate gibt es seit 2014, es steht unter der GPLv2/LGPLv2 Lizenz und hat inzwischen etliche Entwickler gefunden. Das System hat ein lokales Interface, kann als Bibliothek in Applikationen eingebunden werden und setzt eine Reihe von OTA Update Varianten um. Es gibt Yocto- und Buildroot-Integration, Support für U-Boot und Grub sowie ein CPIO basiertes Format für die Updates. Für verschiedene Backend-Store Devices gibt es jeweils Handler, und swupdate lässt sich in LUA scripten. Boot-Counter sind im Zusammenhang mit U-Boot realisiert. Auf der Agenda stehen noch Bootloader Fallback, File Updater, ein Progress-Interface und Streaming-Updates.

Zero-Copy Video Streaming on Embedded Systems the Easy Way

Im letzten Vortrag aus unserem Team stellten Michael Tretter und Philipp Zabel ihre Erfahrungen rund um bandbreitenschonendes Videostreaming vor. Generell geht es darum, mit einem SoC Video vom Sensor zu übernehmen, zu prozessieren, über einen Kommunikationsweg zu übertragen, zu empfangen und anzuzeigen. Dabei gilt es, die hohen Verarbeitungsanforderungen mit stromsparenden Embedded Prozessoren zu verbinden.

Viele Einheiten auf den SoCs brauchen die Daten in speziellen Farbformaten: Kameras liefern für gewöhnlich Bayer-Pattern, die Encoder/Decoder benötigen ein YUV-Format, wohingegen 3D-Einheiten getiledte Formate benötigen. Dazwischen gilt es zu vermitteln, ohne jedoch unnötige Kopien der Daten anzufertigen und damit Bus-Bandbreite zu verschwenden.

Für die 3D Einheiten, die für geometrische Korrekturen (z.B. Linsenentzerrung) verwendet werden, wird das Etnaviv Projekt eingesetzt; die Patche dafür sind inzwischen in MESA und Linux Mainline enthalten. Die Ausgabe-Seite wird mit dem imx-drm Treiber bedient, die Encoder/Decoder Treiber (coda) sind ebenfalls im Kernel enthalten.

Der Schlüssel zum Weiterreichen von Puffern zwischen den Hardware-Geräten ist "dmabuf": Mit diesem Mechanismus ist es möglich, vom Userspace aus ein Handle auf einen Puffer zwischen verschiedenen Kernel-Treibern weiterzureichen, ohne die Daten kopieren zu müssen. Da der Userspace nur den Handle hat, muss man damit keine Adressen mehr in den Userspace exponieren; weiterhin behält der Kernel die Lebensdauer der Puffer vollständig unter Kontrolle.

Nachdem einige v4l2- und EGL-Beispiele gezeigt wurden (die durchaus nicht einfach aussehen), zeigten die Referenten den Einsatz von GStreamer. Damit sind die Beispiele zwar immer noch nicht einfach, man sieht aber nicht mehr so viel davon, wenn man lediglich Applikationen schreibt. Für komplexere Szenarien, in denen auf der Ausgabeseite Compositing zwischen Video und z.B. graphischen Oberflächen benötigt wird, kommt Wayland ins Spiel. Die resultierenden GStreamer-Pipelines sehen nun endlich in der Tat einfach aus.

Leider ist eine Kamera-Input-Pipeline weiterhin komplex und muss über media-ctl konfiguriert werden; hier wird zur Zeit noch Arbeit investiert, um sinnvolle Defaults zu ermitteln. Auf der Weston-Seite gibt es schon Patche für atomares Mode-Settings, die noch nicht in Mainline gelandet sind.

Closing Game & Attendee Party