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 »