lkm sandbox
1.0.0
Modules / bâtiment / make / test / POC / répétition / notes / clause de non-responsabilité / licence / livres / liens
Le sandbox du module du noyau Linux (LKM) est une collection de différents modules pour apprendre, découvrir et expérimenter le développement de modules de noyau Linux. Le but de ce référentiel est également de pratiquer le développement au sein du noyau Linux et d'étudier les concepts divers avant de passer à soumettre le tout premier patch au noyau.
La plupart des modules illustrent un concept et montrent comment utiliser l'API du noyau. Quelques-uns des modules combinent plus d'un concept pour présenter comment les concepts fonctionnent ensemble. Par exemple, le module lkm_device accéde à un périphérique de caractères et stockage son numéro majeur dans / proc. Ou le module LKM_MEM exposent également des informations de mémoire / swap par fichiers dans / proc.
J'espère que cela peut être utile pour d'autres développeurs qui essaient d'approcher le noyau Linux.
| Non. | Module | Source | Description |
|---|---|---|---|
| 1 | LKM Debugfs | LKM_DEBUGFS.C | Module montrant comment utiliser le débogage de débogage de fichiers de fichiers |
| 2 | Appareil LKM | lkm_device.c | Module montrant comment fonctionner avec des périphériques de caractère et stockant les informations de l'appareil dans / proc |
| 3 | Numéros de périphérique LKM | lkm_device_numbers.c | Illustrer les numéros de périphériques alloués statiquement et dynamiquement |
| 3 | Mémoire LKM | lkm_mem.c | Module exposant la mémoire et échanger des informations à / proc |
| 4 | Appareil basé sur la mémoire LKM | lkm_mev.c | Pilote d'un appareil de caractère basé sur la mémoire, basé dans une certaine mesure sur Scull, développé dans le livre Linux Device Drivers, chapitre 3 |
| 5 | Paramètres LKM | lkm_parameters.c | Module pour passer les paramètres de l'utilisateur à Kernelspace |
| 6 | LKM Pretty Printk | lkm_pp.c | Module pour tester l'intégration de Pretty-Printk |
| 7 | Lkm proc | LKM_PROC.C | Système de fichiers accédant au module / proc utilisant des E / S séquentielles |
| 8 | Processus LKM | lkm_process.c | Accéder et imprimer les informations actuelles du processus |
| 9 | Bac à sable LKM | lkm_sandbox.c | Module de bac à sable pour différentes expériences |
| 10 | Squelette LKM | lkm_skeleton.c | Module squelette pour échafaudage plus rapide de nouveaux modules |
Lors du clonage pour la première fois, veuillez également cloner les sous-modules avec --recurse-submodules pour devenir assez imprimé.
git clone --recurse-submodules [email protected]:tpiekarski/lkm-sandbox.gitmake clean && make
Pour exécuter tous les tests disponibles, y compris le chargement / le déchargement de base et tous les tests conceptuels supplémentaires.
make testTester en chargeant, déchargeant et sortie du tampon de bague du noyau (Sudo demandera des autorisations racines).
make test-module name= < module-name > Des tests supplémentaires pour le périphérique de bac à sable, y compris le chargement du module, la collecte du numéro de périphérique majeur à partir de / proc, la création d'un appareil et la comparaison du message final exécutent la cible MakeFile avec make test-device ou exécutez les commandes suivantes.
Pour créer un périphérique de caractères, le numéro majeur est nécessaire et peut être obtenu en caressant le fichier / proc / lkm_device_major. Ce numéro majeur est également écrit dans le tampon d'anneau de noyau. Il est possible de fournir ce nombre majeur en utilisant le paramètre du module param_major_num et de charger ce module comme sudo insmod lkm_device.ko param_major_num=241 (à ce moment, cette allocation statique ne semble pas être fiable. L'enregistrement de l'appareil de sable échoue parfois.
sudo insmod lkm_device.ko
dmesg | grep " Registered sandbox device "
sudo mknod /dev/lkm_device c $( cat /proc/lkm_device_major ) 0
test -c /dev/lkm_device && cat /dev/lkm_device || echo " Device /dev/lkm_device " not found. "
sudo rmmod lkm_device Des tests supplémentaires pour l'accès au bac à sable à / proc, y compris le module de chargement, tester si le fichier à l'intérieur / proc existant et la sortie de ce fichier. Soit exécuter le makeFile Target Test-Proc avec make test-proc ou les quelques commandes suivantes:
sudo insmod lkm_proc.ko
test -f /proc/lkm_proc && cat /proc/lkm_proc || echo " File /proc/lkm_proc not found. "
sudo rmmod lkm_proc Pour des tests supplémentaires pour passer des paramètres au module LKM_PARAMETERS, exécutez le paramètre de test cible de MakeFile avec make test-parameters . Cela chargera / déchargera le module et comparera le numéro de paramètres et le message passé lors du chargement du module avec les valeurs lues dans le système de fichiers / sys (/ sys / module / lkm_parameters / paramètres / *). Ou exécutez les commandes suivantes.
sudo insmod lkm_parameters.ko number=33 message= " Some message... "
cat /sys/module/lkm_parameters/parameters/number
cat /sys/module/lkm_parameters/parameters/message
sudo rmmod lkm_parametersPendant le triage, le débogage et le travail avec des bogues et des problèmes, il peut être utile d'expérimenter avec un code et d'écrire un POC pour prouver certaines déclarations ou de répondre à une question. Dans ce qui suit se trouvent une collection de tels POC qui suivent une avance à prouver des déclarations, des idées et des questions que j'ai récemment rencontrées.
| Déposer | Description | Motivation |
|---|---|---|
| Comparaison-iopl-ioperm.c | Comparaison des autorisations d'E / S accordées par IOPL et IOperm | Bogue 205317 - IOPL (2) - Le niveau de privilège est défini par processus ou par thread? |
| Permissions-Revisite.C | Comment les autorisations d'E / S sont-elles accordées lors de l'utilisation du clone, de la fourche, de l'EXECVE ou du pthread? | Bogue 205317 - IOPL (2) - Le niveau de privilège est défini par processus ou par thread? |
Pour une meilleure compréhension des concepts dans l'espace de noyau, il est nécessaire d'examiner et de répéter les bases fondamentales de C et de la bibliothèque standard. À côté de pouvoir améliorer la compréhension, il est possible de comparer les approches. La plupart de ces bases sont de bas niveau, en commençant par des E / S de fichiers et peuvent être considérées comme une source complémentaire. Il n'est jamais mauvais de répéter les choses, mais parfois un peu gênant d'admettre avoir à répéter de telles choses :)
| Déposer | Concept |
|---|---|
| clone.c | Processus de clonage avec clone () |
| execve.c | Exécuter un autre processus avec execve () |
| fork.c | Création d'un processus d'enfant avec Fork () |
| io_ports.c | Opérations d'E / S à port port |
| lire.c | Lecture de fichiers dans Vanilla C |
| Simple_circular_buffer.c | Tampon circulaire simple et simple |
| écrire.c | Écriture / appliquer dans des fichiers en vanille C |
Pour construire ces fichiers, il suffit make clean && make ./rehearsals/ et tous les exécutables seront placés dans le répertoire de build.
"Un module du noyau Linux est un morceau de code binaire compilé qui est inséré directement dans le noyau Linux, fonctionnant à l'anneau 0, l'anneau d'exécution le plus bas et le moins protégé dans le processeur x86–64."
"Les paradigmes de développement d'applications traditionnels peuvent être largement jetés. À part le chargement et le déchargement de votre module, vous écrirez du code qui répond aux événements système plutôt que fonctionne dans un modèle séquentiel."
"Avec le développement du noyau, vous écrivez des API, pas des applications elles-mêmes."
Ce référentiel vous demandera l'autorisation racine, car certaines opérations comme le chargement / déchargement des modules et l'accès aux fichiers dans le système Linux / GNU dépend des privilèges racine. Le Makefile indiquera à l'avance pour ce que ces autorisations seront utilisées.
Vous pouvez consulter toutes ces opérations en recherchant ce référentiel pour Sudo et assurer que cela ne sera en aucun cas utilisé à mauvais escient. Je suis conscient que cela peut être un problème de sécurité, mais j'essaie de rendre ce processus autant de transparent que possible. Mais sachez également que ces modules arrivent sans aucune garantie. Les paniques du noyau et la perte de données peuvent se produire, veuillez les utiliser de préférence dans une machine virtuelle.
Dans ce qui suit se trouve un tableau avec tous les emplacements où Sudo est utilisé (sauf le Readme.md).
grep -n -r " sudo " *| Dossier: ligne | Utilisation de Sudo |
|---|---|
| Makefile: 118 | |
| Makefile: 119 | $ (eval numéro_file_content = sudo cat $(number_file) )) |
| Makefile: 122 | |
| Makefile: 123 | |
| Makefile: 126 | @sudo rmmod $ (module_filename) |
| Makefile: 140 | @sudo mknod $ (device_filename) C cat $(proc_filename) 0 |
| Makefile: 143 | @sudo rm $ (device_filename) |
| Makefile: 144 | @sudo rmmod $ (module_filename) |
| Makefile: 162 | @sudo rmmod $ (module_filename) |
| Makefile: 175 | @sudo mknod |
| Makefile: 176 | @Echo "Testing" | sudo tee $ (device_file) |
| Makefile: 178 | @sudo rm -fv $ (device_file) |
| Makefile: 179 | @sudo rmmod $ (module) |
| Makefile: 190 | @sudo insmod |
| Makefile: 193 | @sudo rmmod $ (module) |
| Makefile: 207 | @sudo rmmod $ {module} |
| Makefile: 219 | @sudo insmod $ (module) .ko |
| Makefile: 222 | @sudo rmmod $ (module) |
| tests.mk:31 | @lsmod | awk '{print $$ 1}' | grep -qe "^ $ (1) $$" && (sudo rmmod |
| tests.mk:75 | @sudo dmesg - Clear |
| tests.mk:78 | @sudo rmmod $ (1) |
LKM Sandbox est un logiciel gratuit: vous pouvez le redistribuer et / ou le modifier en vertu des termes de la licence publique générale GNU publiée par la Free Software Foundation, soit la version 2 de la licence, ou (à votre option) n'importe quelle version ultérieure.
LKM Sandbox est distribué dans l'espoir qu'il sera utile, mais sans aucune garantie; Sans même la garantie implicite de qualité marchande ou d'adéquation à un usage particulier. Voir la licence publique générale GNU pour plus de détails.
Vous devriez avoir reçu une copie de la licence publique générale GNU avec LKM Sandbox. Sinon, voir https://www.gnu.org/licenses/.
