Christophe Blaess

Lorsqu’on réalise un build pour un système Linux embarqué avec Yocto Project, de nombreux fichiers sont parcourus par l’outil Bitbake. Il n’est pas toujours simple de savoir dans quel ordre ces fichiers de configuration sont examinés, mais c’est pourtant une clé pour la bonne compréhension des opérations réalisées.

Nous allons nous intéresser ici aux fichiers de configuration et de données (distro, machine, image, recettes, etc.) pas aux fichiers python internes de Bitbake, ni aux fichiers sources, objets ou exécutables obtenus lors de la compilation des packages.

Bien sûr nous regarderons certains fichiers directement livrés avec Yocto, mais ce qui m’intéresse avant tout, c’est la connaissance des fichiers sur lesquels nous avons la possibilité d’agir, ceux que nous pouvons personnaliser avant de lancer le build.

Pas de commentaires»

Pour des applications où l’aspect sécurité est particulièrement important, on souhaite souvent s’assurer de l’intégrité de l’espace mémoire et des activités du noyau Linux. Pour cela on vérifie que les modules chargés dynamiquement dans le noyau (les fichiers avec l’extension .ko) sont bien conformes à ceux prévus à la production du système en les signant cryptographiquement.

Si cette étape est souvent réalisée automatiquement pour les distributions Linux courantes (voir par exemple https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html), elle est un peu moins simple à mettre en oeuvre pour les systèmes embarqués produits avec Yocto.

Lors d’une récente session de formation « Écriture de drivers pour Linux » que j’animais pour Logilin, un participant m’a interrogé sur les méthodes à employer pour signer les modules dans un contexte de système embarqué. Nous n’avons pas eu le temps de développer ce sujet durant cette session, mais j’ai voulu détailler ce thème dans ce petit article.

2 commentaires »

La fonctionnalité LFS (Large File Support) permet de superviser avec git des fichiers volumineux en évitant les téléchargements longs. Lors d’une opération git clone, le fichier original est remplacé par un fichier de référence beaucoup plus petit. Le remplacement inverse par le contenu initial n’a lieu que sur demande explicite.

Les anciennes versions de Yocto Project étaient capable d’extraire automatiquement les contenus LFS, mais il semble que cette fonctionnalité ait disparue depuis la branche Kirkstone de Poky. Nous pouvons y remédier assez simple en appelant explicitement git lfs pull dans une recette. Toutefois, l’écriture de la fonction nécessaire n’est pas intuitive et s’avère plutôt intéressante.

Pas de commentaires»

Dans beaucoup de systèmes embarqués, il est important de réaliser certaines tâches au démarrage le plus rapidement possible et dans un ordre précis. Citons par exemple l’affichage d’un écran splashscreen, le montage d’une partition de données, l’initialisation des interfaces réseau, ou la mise à l’heure du système.

Or les systèmes d’initialisation modernes, comme systemd, sont prévus pour fonctionner sur des serveurs ou des postes de travail, sur lesquels l’ordre d’exécution et la rapidité des tâches d’initialisation ne sont pas primordiaux.

Il est facile de résoudre ce problème avec un petit script, nommé early-init, que je souhaite vous présenter ici.

Lire la suite de cette entrée »

Pas de commentaires»