Sie brauchen wahrscheinlich kein Yocto, und das ist auch gut so

Neue Kunden reagieren oft überrascht, wenn wir in der Planungsphase fragen, ob sie Yocto wirklich brauchen. Die unausgesprochene Annahme lautet meist, dass jedes ernsthafte Embedded-Linux-Projekt heutzutage Yocto einsetzen muss. Wir bei der sigma star gmbh sehen uns als Power-User und Yocto-Experten. Genau deshalb sind wir oft diejenigen, die unseren Kunden raten, es sich zweimal zu überlegen, bevor sie zu Yocto greifen. Warum ist Yocto also die Standardwahl, und wann ist es die falsche Standardwahl?

Was ist Yocto eigentlich?

Manchmal wird es “die Yocto-Linux-Distribution” genannt. Das ist es nicht. Yocto ist ein Werkzeugkasten, um Ihre eigene Linux-Distribution zu bauen. Das Yocto-Projekt selbst liefert eine Referenzdistribution namens Poky, gebaut aus bitbake, openembedded-core und meta-yocto¹.

Die Möglichkeit, ein Linux-System zusammenzustellen, das genau Ihren Anforderungen entspricht, macht Yocto für Embedded-Projekte enorm mächtig. Sie können den gesamten User Space für Ihre CPU kompilieren, jede Komponente patchen, in jeder Recipe Features ein- oder ausschalten und jede Version festpinnen oder ändern. Darüber hinaus veröffentlichen viele System-on-Chip-Hersteller (SoC) und Hardwarepartner fertige Board-Support-Package-Layer (BSP), die Ihnen einen funktionierenden Ausgangspunkt auf echter Hardware geben.

Diese Mischung aus Flexibilität und Herstellerunterstützung macht Yocto zur Standardwahl. Dieselbe Mischung macht Yocto aber auch zur Falle, wenn Sie so viel Kontrolle gar nicht brauchen.

Ihre Distribution, Ihre Verantwortung

Mit Regularien wie dem Cyber Resilience Act (CRA)² müssen Produkthersteller die ausgelieferte Software nun sicher halten und über die gesamte Produktlebensdauer Sicherheitsupdates bereitstellen. Das kann eine lange Zeit sein, um ein Linux-System zu warten.

Ein reguläres Yocto-Release wird nur etwa sieben Monate lang gepflegt, bis das nächste Release erscheint. Long-Term-Support-Releases (LTS) erhalten bis zu vier Jahre Updates, so die aktuelle Richtlinie seit Yocto 5.0 (Scarthgap)³.

Man könnte fragen, warum vier Jahre nicht genügen. Doch es gibt ein weniger offensichtliches Problem. Um es zu erkennen, müssen wir uns ansehen, was in einem Yocto-LTS-Release tatsächlich gepflegt wird.

Ein Yocto-Release ist eine Sammlung von bitbake-Recipes für Softwarekomponenten, mit bestimmten Versionen und Metadaten, plus der Referenzdistribution Poky. Während des Wartungszeitraums spielen die Yocto-Maintainer Bug- und Security-Fixes in diese Komponenten und in Poky ein. Bei Softwarekomponenten haben diese Fixes meist die Form von Backports aus neueren Upstream-Versionen.

Und jetzt kommt der Haken. Da Yocto ein Werkzeug ist, um Ihre eigene Distribution zu bauen, haben Sie höchstwahrscheinlich Änderungen wie diese vorgenommen:

• Nicht triviale Patches oder lokale Anpassungen an einer Handvoll Komponenten.
• Zusätzliche Komponenten, die über das hinausgehen, was Yocto mitliefert.
• Versions-Bumps oder Pins, um einen Fix mitzunehmen oder einen bekannt guten Stand zu halten.

Mit jedem Yocto-Wartungs-Release müssen Sie prüfen, ob sich Ihre Änderungen noch sauber auf den neuen Stand anwenden lassen. Zusätzlich müssen Sie sicherstellen, dass die Komponenten, die Sie hinzugefügt oder gepinnt haben, weiterhin von irgendwoher Fixes erhalten, denn die Yocto-Maintainer wissen nichts von ihnen. Unterm Strich ist es Ihre Wartungsarbeit.

Wenn Sie Poky nehmen und es fast unverändert verwenden, ist eine berechtigte Frage: Warum verwenden Sie überhaupt Yocto?

Was gerne verschwiegen wird: der Linux-Kernel

Yocto liefert einen Linux-Kernel und wartet ihn als Teil jedes Releases. Doch Sie werden ihn wahrscheinlich nicht unverändert verwenden. Fast immer müssen Sie zumindest die Patches Ihres Herstellers anwenden und einen Kernel betreiben, der neu genug ist, um die Treiber und Fixes zu enthalten, auf die Sie angewiesen sind. Sobald Sie also das CVE-Tracking einrechnen, ist allein der Kernel ein großer Teil Ihrer Wartungsarbeit, ob Sie Yocto verwenden oder nicht.

Es gibt einen Weg, diese Arbeit im Griff zu behalten. Wir raten unseren Kunden dringend, auf einem LTS-Kernel von kernel.org⁴ aufzubauen und alle ihre Änderungen in einer sauberen Patch-Queue zu halten. Um bei den Sicherheitsfixes aktuell zu bleiben, wechseln Sie auf jedes neue Stable-Release und wenden die Patch-Queue erneut an. kernel.org pflegt LTS-Kernel über Jahre, daher lässt sich Ihre Patch-Queue meist sauber anwenden und erfordert nur dann echten Aufwand, wenn Sie auf ein neues LTS-Release springen.

Je nach Ihrem Setup und Ihren Sicherheitsanforderungen gilt dasselbe für den Bootloader, der meist genauso herstellerspezifisch ist.

Und der Vollständigkeit halber: Beim Kernel zu bleiben, den Ihr Hersteller mitliefert, ist meist eine schlechte Idee. Hersteller-Kernel liegen Jahre hinter kernel.org zurück, erhalten selten Updates und verpassen fast alle Sicherheitsfixes. Ausnahmen bestätigen die Regel.

Die versteckten Kosten einer eigenen Distribution

“Ihre eigene Distribution” zu bauen klingt auf einer Präsentationsfolie großartig. In der Praxis kostet es echte Entwicklungszeit.

• Build-Zeiten. Yocto kompiliert praktisch alles aus dem Quelltext. Ein sauberer Build eines nicht trivialen Images dauert auf einer schnellen Workstation Stunden. Der sstate-cache und ein gemeinsames DL_DIR beschleunigen wiederholte Builds, doch der Cache selbst ist fragil: eine kleine Änderung an einer Recipe kann große Teile davon ungültig machen.
• Speicher- und CI-Kosten. Ein aktives Yocto-Build-Verzeichnis erreicht leicht 100 GiB oder mehr. CI-Runner brauchen üppigen Speicher und eine Möglichkeit, sstate zwischen Jobs zu teilen. Sie können sstate und DL_DIR spiegeln, um das erträglicher zu machen, doch diese Infrastruktur müssen Sie selbst betreiben.
• Lernkurve. bitbake-Recipes, Layer, dynamische Layer, Klassen, Overrides, bbappend-Dateien, PACKAGECONFIG, der Unterschied zwischen DEPENDS und RDEPENDS: die Liste der Dinge, die Sie verinnerlichen müssen, bevor Sie ein Yocto-Image ausliefern können, ist lang. Neue Entwickler in eine Yocto-Codebasis einzuarbeiten dauert Wochen, nicht Tage.
• Die Qualität der BSP-Layer schwankt. Manche SoC-Hersteller liefern saubere, gut gepflegte BSP-Layer. Andere liefern einen meta-vendor-Layer, der einen fünf Jahre alten Kernel oder Bootloader festpinnt, maschinenspezifische Recipes fest in die falschen Layer schreibt und bei jedem Poky-Bump kaputtgeht. Aus diesem “guten Ausgangspunkt” kann der schlimmste Teil Ihres Builds werden.

Nichts davon ist ein Grund, Yocto zu meiden. Es ist ein Grund, sich zu vergewissern, dass Sie es wirklich brauchen, bevor Sie sich festlegen.

Eine Alternative: eine etablierte Distribution wiederverwenden

Wenn Sie in Wahrheit nur ein solides Linux-Fundament brauchen, auf dem Ihre Anwendung läuft, löst eine etablierte Distribution wie Debian GNU/Linux die meisten dieser Probleme mit deutlich weniger Aufwand pro Projekt⁵.

Debian liefert heute rund 70.000 Binärpakete, gebaut für alle gängigen Architekturen: amd64, i386, arm64, armhf, riscv64, ppc64el und eine Handvoll weiterer⁶. Die Chancen stehen gut, dass Ihr SoC diese Binaries direkt ausführen kann, ohne dass eine Neukompilierung nötig ist.

Debian liefert nicht nur einen modernen User Space mit systemd, udev und dbus. Das Archiv enthält auch alles, was Sie brauchen, um kleine Linux-Systeme mit SysV-artigem Init oder BusyBox zu bauen. Sie wählen eine schlanke Basis, installieren nur die Pakete, die Ihr Produkt braucht, und profitieren trotzdem von der Arbeit der Debian-Paketbetreuer.

Wartung von Debian

Debian stable erhält vom Debian Security Team rund drei Jahre lang Sicherheitsupdates. Danach verlängert das Debian-LTS-Projekt, eine Gemeinschaftsinitiative, die Unterstützung um etwa zwei weitere Jahre auf den gängigen Architekturen⁷. In der Praxis ergibt das rund fünf Jahre pro Release, nahe an einem Yocto-LTS, aber mit weit weniger Aufwand pro Projekt.

Um die neuesten Fixes mitzunehmen, holen Sie die aktuellen Debian-Pakete und erzeugen Ihr Image neu. Verglichen mit einem Yocto-Setup, in dem Sie Upstream-Patches selbst backporten oder erneut prüfen müssen, ob sich Ihre lokalen Änderungen noch auf ein Wartungs-Release anwenden lassen, ist das eine andere Welt.

Wie entsteht ein Embedded-Image eigentlich?

An diesem Punkt kommen die meisten üblicherweise durcheinander. Sie stellen sich vor, ein SoC von einem USB-Stick zu booten und den Debian-Installer auszuführen. Das ist nicht gemeint.

Die Idee ist, auf einem Build-Host ein flashbares Image zu erzeugen und es auf das Gerät zu schreiben. Dazu brauchen Sie:

• Einen Bootloader, meist SoC-spezifisch (etwa u-boot).
• Einen Linux-Kernel, ebenfalls meist SoC-spezifisch.
• Ein Root-Dateisystem mit dem Linux-User-Space, direkt aus Debian übernommen.
• Ein Tool zum Zusammenbauen des Images, das die drei zu einem flashbaren Image zusammenfügt.

Für dieses letzte Stück sind die drei üblichen Verdächtigen mkosi⁸, ELBE⁹ und debos¹⁰.

Alle drei sind freie Software, und alle drei erzeugen ein deterministisches Image, das Sie auf Ihre Hardware flashen können. Die Wartungsarbeit schrumpft drastisch: die meisten Updates werden zu einer apt-artigen Aktualisierung der Pakete im Image, nicht zum Umschreiben einer Recipe.

Beispiel: debos

Um den Debian-Weg greifbar zu machen, sieht ein debos-basierter Build grob so aus.

debos liest eine YAML-Recipe: eine Liste von Actions wie das Ausführen eines Kommandos, das Erzeugen eines Root-Dateisystems oder das Installieren eines Debian-Pakets aus einer konfigurierten Quelle.

Der grundlegende Ablauf sieht so aus:

• Verwenden Sie aptly¹¹, um einen lokalen Debian-Mirror zu betreiben, der eine Kopie jedes benötigten Debian-Pakets vorhält.
• Bauen Sie Ihren Linux-Kernel und, optional, Ihren Bootloader als Debian-Pakete und fügen Sie sie dem Mirror hinzu.
• Erstellen Sie einen Snapshot des Mirrors und versehen Sie den Snapshot mit einem Tag. Dieser Tag ist Ihr Release.
• Konfigurieren Sie debos so, dass es den Mirror verwendet, und schreiben Sie Recipe-Actions, die Ihr Ziel-Image erzeugen.
• Archivieren Sie bei Bedarf die Debian-Quellpakete und die Software Bill of Materials (SBOM) des Images zusammen mit dem Image. So bleiben Sie auf der sicheren Seite bei den GPL-Anforderungen zur Quelltextverfügbarkeit und den CRA-Vorgaben zur Stückliste. Tools wie debsbom¹² erzeugen die SBOM direkt aus einem Debian-System.

Yocto oder nicht? Eine Entscheidungshilfe

Nach all dem: Wann sollten Sie Yocto wählen?

Verwenden Sie Yocto, wenn:

• Sie eine stark angepasste Distribution brauchen: eigener User Space, eigene Compile-Flags, tiefe Eingriffe in Basiskomponenten.
• Sie harte Vorgaben bei Größe oder Bootzeit haben, die eine Distribution von der Stange nicht erfüllt.
• Sie unter Lizenzbeschränkungen arbeiten, die gängige Lizenzkategorien ausschließen. Manche Branchen (Medizingeräte, Automotive, bestimmte Rüstungsprojekte) liefern keine GPLv3-Komponenten aus. Yoctos INCOMPATIBLE_LICENSE-Mechanismus macht es unkompliziert, eine ganze Lizenzfamilie über das gesamte Image auszuschließen; bei einer unveränderten Debian-Basis müssen Sie die Pakete selbst prüfen und ausdünnen.
• Der offizielle Support-Weg Ihres SoC-Herstellers Yocto ist und das BSP solide ist.

Verzichten Sie auf Yocto, wenn:

• Sie “nur” ein modernes Linux brauchen, auf dem Ihre Anwendung läuft.
• Ihr Budget an Speicher und Arbeitsspeicher ein normales Debian-basiertes Image verkraftet (etwa einige Hundert MB Flash und 256 MB oder mehr RAM).
• Die Produktlebensdauer lang genug ist, dass Sie sich lieber auf das Security Team von Debian verlassen, als selbst zu warten.

Verzichten Sie auf Debian, wenn:

• Sie viele seiner Pakete ändern oder neu bauen müssen. Ein paar neu zu bauen ist machbar, doch jedes neu gebaute Paket ist Wartung, die Sie selbst übernehmen. Dutzende Upstream-Pakete zu patchen schafft genau die Arbeit wieder, die die Debian-Betreuer für Sie erledigt haben, und Yoctos Recipe-Modell bewältigt diese Größenordnung sauberer.
• Sie eine libc jenseits von glibc brauchen, etwa musl oder uClibc. Debians Hauptarchiv verwendet durchgehend glibc; sie auszutauschen bedeutet, den Großteil des Archivs selbst neu zu bauen.
• Sie Software brauchen, die deutlich neuer ist als das, was Debian stable liefert. Backports helfen bei manchen Paketen, doch wenn Ihr Produkt einen aktuellen Compiler oder eine aktuelle Laufzeitumgebung braucht, macht Ihnen Debian stable das Leben schwer, und Debian testing ist kein Produktionsziel.

Wie auch immer Sie sich entscheiden, entscheiden Sie bewusst und entscheiden Sie früh. Das ist eine grundlegende Entscheidung, die sich schwer rückgängig machen lässt, sobald ein Produkt im Feld ist. Im Zweifel beginnen Sie mit einer etablierten Distribution. Später zu Yocto zu migrieren, sobald Sie einen echten Grund dafür haben, ist viel günstiger als der umgekehrte Fall: mitten im Projekt festzustellen, dass Sie sich jahrelange Wartungsarbeit ohne echten Nutzen aufgehalst haben.

Fazit

Yocto ist eine bemerkenswerte technische Leistung. Damit bauen Sie genau das Linux-System, das Sie brauchen, und genau das ist das Problem, wenn Sie genau das nicht brauchen. Dasselbe gilt für andere Tools, die aus dem Quelltext bauen, etwa Buildroot: fast alles oben Gesagte trifft auch dort zu, denn sobald Sie Ihre eigene Distribution zusammenstellen, gehört Ihnen ihre Wartung.

• “Ihre eigene Distribution” bedeutet in Wahrheit Ihre eigene Wartung. Der CRA und ähnliche Regularien machen diese Rechnung fällig.
• Ein stark angepasster Yocto-Build erbt Upstream-Fixes nicht gratis. Jedes Wartungs-Release wird zu Prüfung und Nacharbeit.
• Eine etablierte Distribution wie Debian, mit mkosi, ELBE oder debos zu einem Image zusammengefügt, deckt den Normalfall mit einem Bruchteil des Aufwands pro Projekt ab.
• Wenn Sie chirurgisch genaue Kontrolle über das System brauchen, gewinnt Yocto. Wenn nicht, ist seine Wahl ein langer, teurer Weg, ein Problem zu lösen, das Sie gar nicht haben.

Kunden, die eine maßgeschneiderte Distribution bauen, empfehlen wir immer Yocto. Allen anderen stellen wir immer wieder dieselbe Frage: Brauchen Sie es wirklich?