{"id":6126,"date":"2024-06-25T06:32:08","date_gmt":"2024-06-25T05:32:08","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=6126"},"modified":"2024-06-25T06:32:10","modified_gmt":"2024-06-25T05:32:10","slug":"signer-ses-modules-kernel-avec-yocto-project","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2024\/06\/25\/signer-ses-modules-kernel-avec-yocto-project\/","title":{"rendered":"Signer ses modules kernel avec Yocto Project"},"content":{"rendered":"
\n
\"\"<\/a><\/figure><\/div>\n\n\n

Pour des applications o\u00f9 l’aspect s\u00e9curit\u00e9 est particuli\u00e8rement important, on souhaite souvent s’assurer de l’int\u00e9grit\u00e9 de l’espace m\u00e9moire et des activit\u00e9s du noyau Linux. Pour cela on v\u00e9rifie que les modules charg\u00e9s dynamiquement dans le noyau (les fichiers avec l’extension .ko<\/code>) sont bien conformes \u00e0 ceux pr\u00e9vus \u00e0 la production du syst\u00e8me en les signant cryptographiquement.<\/p>\n\n\n\n

Si cette \u00e9tape est souvent r\u00e9alis\u00e9e automatiquement pour les distributions Linux courantes (voir par exemple https:\/\/www.kernel.org\/doc\/html\/latest\/admin-guide\/module-signing.html<\/a>), elle est un peu moins simple \u00e0 mettre en oeuvre pour les syst\u00e8mes embarqu\u00e9s produits avec Yocto.<\/p>\n\n\n\n

Lors d’une r\u00e9cente session de formation \u00ab\u00a0\u00c9criture de drivers pour Linux<\/a>\u00a0\u00bb que j’animais pour Logilin, un participant m’a interrog\u00e9 sur les m\u00e9thodes \u00e0 employer pour signer les modules dans un contexte de syst\u00e8me embarqu\u00e9. Nous n’avons pas eu le temps de d\u00e9velopper ce sujet durant cette session, mais j’ai voulu d\u00e9tailler ce th\u00e8me dans ce petit article.<\/p>\n\n\n\n\n\n\n\n

Installation d’un module kernel personnalis\u00e9 avec Yocto Project<\/h2>\n\n\n\n

Les fichiers sources pr\u00e9sent\u00e9s ci-dessous sont disponibles ici : https:\/\/github.com\/cpb-\/meta-signing-modules<\/strong><\/a>.<\/p>\n\n\n\n

Commen\u00e7ons par \u00e9crire un module kernel minimal nomm\u00e9 my-module.c<\/a><\/strong><\/code> :<\/p>\n\n\n\n

\/\/ SPDX-License-Identifier: GPL-2.0\n\/\/\n\/\/ (c) 2024 Christophe Blaess\n\/\/    https:\/\/www.logilin.fr\/\n\n#include <linux\/module.h>\n\nstatic int __init my_module_init(void)\n{\n    pr_info(\"%s: Hello guys!\\n\", THIS_MODULE->name);\n    return 0;\n}\n\nstatic void __exit my_module_exit(void)\n{\n    pr_info(\"%s: That's all folk!\\n\", THIS_MODULE->name);\n}\n\nmodule_init(my_module_init);\nmodule_exit(my_module_exit);\n\nMODULE_DESCRIPTION(\"My custom module.\");\nMODULE_AUTHOR(\"Christophe Blaess <christophe.blaess@logilin.fr>\");\nMODULE_LICENSE(\"GPL v2\");<\/code><\/pre>\n\n\n\n
Ce fichier source est accompagn\u00e9 d’un fichier Makefile<\/a><\/strong><\/code> typique d’un module du kernel :<\/p>\n\n\n\n
# SPDX-License-Identifier: GPL-2.0\n\nifneq ($(KERNELRELEASE),)\n\n    obj-m += my-module.o\nelse\n    KERNEL_DIR ?= \/lib\/modules\/$(shell uname -r)\/build\n    MODULE_DIR := $(shell pwd)\n\n.PHONY: all modules clean\n\nall: modules\n\nmodules:\n    $(MAKE) -C $(KERNEL_DIR) M=$(MODULE_DIR)  modules\n\nclean:\n    rm -f *.o *.ko *.mod.c .*.o .*.o.d .*.ko .*.mod.c .*.cmd *~ *.ko.unsigned *.mod\n    rm -f Module.symvers Module.markers modules.order\n    rm -rf .tmp_versions .cache.mk\nendif<\/code><\/pre>\n\n\n\n
Enfin, une recette pour Yocto Project permet de compiler ce module. Ce fichier my-module.bb<\/a><\/strong><\/code> est plac\u00e9 dans un layer personnalis\u00e9.<\/p>\n\n\n\n
LICENSE = \"GPL-2.0-only\"\nLIC_FILES_CHKSUM = \"file:\/\/${COMMON_LICENSE_DIR}\/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6\"\n\nSRC_URI += \"file:\/\/my-module.c\"\nSRC_URI += \"file:\/\/Makefile\"\n\ninherit module\n\nS = \"${WORKDIR}\"\n\nEXTRA_OEMAKE:append:task-install = \" -C ${STAGING_KERNEL_DIR} M=${S}\"\nEXTRA_OEMAKE += \"KERNEL_DIR=${STAGING_KERNEL_DIR}\"<\/code><\/pre>\n\n\n\n
Voici l’organisation sommaire de ce layer sp\u00e9cifique :<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Commen\u00e7ons par faire une compilation pour une image minimale (core-image-base<\/strong><\/code>). J’ai int\u00e9gr\u00e9 le layer personnalis\u00e9 dans conf\/bblayers.conf<\/strong><\/code> et ajout\u00e9 les deux lignes suivantes dans conf\/local.conf<\/strong><\/code> :<\/p>\n\n\n\n
IMAGE_INSTALL:append = \" my-module\"\nMACHINE = \"qemuarm\"<\/code><\/pre>\n\n\n\n
J’ai utilis\u00e9 la version de Yocto Project la plus r\u00e9cente au moment de l’\u00e9criture de cet article (branche Scarthgap<\/em> de Poky, release<\/em> 5.0.1), mais ce que nous allons voir ici devrait \u00eatre valable quelque soit la version.<\/p>\n\n\n\n
Une fois le build<\/em> termin\u00e9, je d\u00e9marre ma cible Qemu et je teste le chargement du module :<\/p>\n\n\n\n
\nPoky (Yocto Project Reference Distro) 5.0.1 qemuarm \/dev\/ttyAMA0\n\nqemuarm login: root<\/strong>\n\nWARNING: Poky is a reference Yocto Project distribution that should be used for\ntesting and development purposes only. It is recommended that you create your\nown distribution for production use.\n\nroot@qemuarm:~# cat \/proc\/sys\/kernel\/tainted <\/strong>\n0\nroot@qemuarm:~# modprobe my-module<\/strong>\n[   25.224565] my_module: loading out-of-tree module taints kernel.\n[   25.227876] my_module: Hello guys!\n\nroot@qemuarm:~# cat \/proc\/sys\/kernel\/tainted <\/strong>\n4096\n\nroot@qemuarm:~# rmmod my-module<\/strong>\n[   34.990447] my_module: That's all folk!\n\n\nroot@qemuarm:~# cat \/proc\/sys\/kernel\/tainted <\/strong>\n4096\n\nroot@qemuarm:~# \n<\/code><\/pre>\n\n\n\n
Nous voyons que le module personnalis\u00e9 est bien install\u00e9 et accessible via modprobe<\/code> (il est install\u00e9 sous \/lib\/modules\/<\/code><kernel-version>\/updates\/<\/code>). Nous pouvons remarquer que le fait de le charger active un flag<\/em> dans le pseudo-fichier \/proc\/sys\/kernel\/tainted<\/code> qui persiste apr\u00e8s le retrait du module.<\/p>\n\n\n\n
Dans ce fichier se trouve des indications de l’historique du kernel depuis le boot<\/em>, entre autres :<\/p>\n\n\n\n