Compiler le module noyau Linux (2.6), y compris les en-têtes non noyaux

Question

Est-il possible de compiler un module de noyau Linux (2.6) incluant les fonctionnalités définies par des inclusions autres que des noyaux?

Par exemple:

kernelmodule.h

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>   // printk()
// ...
#include <openssl/sha.h>
// ...

Makefile

obj-m := kernelmodule.o
all:
    $(MAKE) -C /lib/modules/`uname -r`/build M=`pwd` modules

clean:
    $(MAKE) -C /lib/modules/`uname -r`/build M=`pwd` clean
    $(RM) Module.markers modules.order

Le module de noyau que j'ai écrit et que je tente de compiler contient des fonctionnalités trouvées dans un certain nombre de fichiers d'inclusion openssl.

Le fichier Make standard présenté ci-dessus n'autorise pas les inclus en dehors des en-têtes linux. Est-il possible d'inclure cette fonctionnalité, et si oui, pourriez-vous me diriger dans la bonne direction.

Merci, Mike

Answer 1

Le noyau ne peut pas utiliser le code de l'espace utilisateur et doit être autonome (c'est-à-dire être complètement autonome, pas de bibliothèques). Par conséquent, il ne récupère pas les en-têtes standard.

L’avantage d’essayer de récupérer les en-têtes d’espace utilisateur n’est pas clair. S'il y a des éléments qu'il est valide d'utiliser (des constantes, des macros peut-être pourvu qu'elles n'appellent aucune fonction de l'espace utilisateur), il peut être préférable de les dupliquer et d'inclure uniquement les parties compatibles avec le noyau dont vous avez besoin.

Il n'est pas possible de lier le noyau avec des bibliothèques conçues pour l'utilisateur - même si elles ne font aucun appel au système d'exploitation - car l'environnement de liaison dans le noyau ne peut pas les récupérer.

Au lieu de cela, recompilez toutes les fonctions à utiliser dans le noyau (en supposant qu'elles ne passent aucun appel de système d'exploitation ou de bibliothèque - par exemple, malloc -, auquel cas elles devront de toute façon être modifiées). Intégrez-les dans votre propre bibliothèque pour les utiliser dans les modules de votre noyau.

Les versions récentes de Linux contiennent quand même des fonctions cryptographiques, y compris divers hachages SHA. Vous pouvez peut-être en utiliser une à la place.

Une autre idée serait d’arrêter d’essayer de faire de la cryptographie dans l’espace noyau et de déplacer le code vers l’espace utilisateur. Le code de l'espace utilisateur est plus facile à écrire / déboguer / maintenir, etc.

Answer 2

J'ai pris des morceaux de code utilisateur que j'ai écrits et les ai convertis pour qu'ils fonctionnent dans l'espace du noyau (c'est-à-dire en utilisant kmalloc (), etc.), ce n'est pas si difficile. Cependant, vous êtes limité à la compréhension du C par le noyau, pas à l’espace utilisateur, ce qui diffère légèrement .. en particulier avec divers types d’int standard.

Il est impossible d'établir une liaison avec un espace utilisateur DSO. & # 8212; le noyau Linux est monolithique, complètement autonome. Il n'utilise pas l'espace utilisateur libc, les bibliothèques ou d'autres bits comme d'autres l'ont noté.

9/10 fois, vous trouverez ce dont vous avez besoin quelque part dans le noyau. Il est très probable que quelqu'un d'autre ait rencontré le même besoin que vous et écrit des fonctions statiques dans certains modules pour faire ce que vous voulez. Il suffit de les saisir et de les réutiliser.

Dans le cas de crypto, comme d'autres l'ont déjà dit, utilisez simplement le contenu du noyau. Une chose à noter, vous aurez besoin de leur activation dans kconfig, ce qui peut arriver ou non, selon ce que l'utilisateur sélectionne lors de la construction. Donc, méfiez-vous des dépendances et soyez explicite, vous devrez peut-être pirater quelques entrées dans kconfig qui sélectionnent également l’API de chiffrement de votre choix lorsque votre module est sélectionné. Faire cela peut être un peu pénible lorsqu’on construit à partir d’arbres.

Donc, d’une part, il vous suffit de "copier et renommer des éléments tout en ajoutant des valeurs globales", de l’autre, vous "indiquez aux utilisateurs qu’ils doivent disposer de la source du noyau complet". C’est l’une des bizarreries d’un noyau monolithique.

Avec un micro-noyau, presque tout fonctionne dans l’espace utilisateur, pas de problème de liaison avec un DSO pour certains pilotes ... c’est un problème qui ne se pose pas. Ne prenez pas cette déclaration comme un indice pour relancer la philosophie de conception du noyau dans les commentaires, cela n’entre pas dans le cadre de cette question.