Comment charger des modules du noyau Linux à partir de code C?

Minimum praticable exemple

Testé sur un QEMU + Buildroot VM et Ubuntu 16.04 hôte avec ce simple paramètre de module de l'imprimante .

Nous utilisons le init_module /finit_module et remove_module Les appels système Linux.

Le noyau Linux dispose de deux appels système pour le module d'insertion:

• init_module
• finit_module

et:

man init_module

documents:

La finit_module() de l'appel système est comme init_module(), mais lit le module à charger à partir du descripteur de fichier fd. Il est utile lorsque l'authenticité d'un module du noyau peut être déterminée à partir de son emplacement dans le système de fichiers; dans les cas où cela est possible, les frais généraux de l'aide de signer cryptographiquement modules afin de déterminer l'authenticité d'un module peut être évité. Le param_values argument est que pour init_module().

finit est plus récente et a été ajouté que dans la v3.8. Plus de justification: https://lwn.net/Articles/519010/

glibc ne semblent pas offrir une C wrapper pour eux, afin que nous venons de créer notre propre syscall.

insmod:

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#define init_module(module_image, len, param_values) syscall(__NR_init_module, module_image, len, param_values)
#define finit_module(fd, param_values, flags) syscall(__NR_finit_module, fd, param_values, flags)
int main(int argc, char **argv) {
const char *params;
int fd, use_finit;
size_t image_size;
struct stat st;
void *image;
/* CLI handling. */
if (argc < 2) {
puts("Usage ./prog mymodule.ko [args="" [use_finit=0]");
return EXIT_FAILURE;
}
if (argc < 3) {
params = "";
} else {
params = argv[2];
}
if (argc < 4) {
use_finit = 0;
} else {
use_finit = (argv[3][0] != '0');
}
/* Action. */
fd = open(argv[1], O_RDONLY);
if (use_finit) {
puts("finit");
if (finit_module(fd, params, 0) != 0) {
perror("finit_module");
return EXIT_FAILURE;
}
close(fd);
} else {
puts("init");
fstat(fd, &st);
image_size = st.st_size;
image = malloc(image_size);
read(fd, image, image_size);
close(fd);
if (init_module(image, image_size, params) != 0) {
perror("init_module");
return EXIT_FAILURE;
}
free(image);
}
return EXIT_SUCCESS;
}

rmmod:

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#define delete_module(name, flags) syscall(__NR_delete_module, name, flags)
int main(int argc, char **argv) {
if (argc != 2) {
puts("Usage ./prog mymodule");
return EXIT_FAILURE;
}
if (delete_module(argv[1], O_NONBLOCK) != 0) {
perror("delete_module");
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}

Busybox source d'interprétation

Busybox fournit insmod, et depuis qu'il est conçu pour le minimalisme, on peut tenter d'en déduire comment il est fait à partir de là.

Sur la version 1.24.2, le point d'entrée est à modutils/insmod.c fonction insmod_main.

La IF_FEATURE_2_4_MODULES est facultatif soutien pour les anciens du noyau Linux 2.4 modules, pour qu'on puisse l'ignorer pour l'instant.

Qui transfère simplement à modutils.c fonction bb_init_module.

bb_init_module tentatives de deux choses l'une:

• mmap le fichier de la mémoire à travers les try_to_mmap_module.

  Cette règle toujours image_size à la taille de la .ko fichier comme un effet secondaire.

• si cela échoue, malloc le fichier dans la mémoire avec la xmalloc_open_zipped_read_close.

  Cette fonction en option dézippe le fichier d'abord si c'est un zip, et juste mallocs c'est le contraire.

  Je ne comprends pas pourquoi cette compression de faire des affaires, car nous ne pouvons même pas compter sur elle car la try_to_mmap_module ne semble pas décompresser les choses.

Enfin, vient l'appel:

init_module(image, image_size, options);

où image est l'exécutable qui a été mis en mémoire, et les options sont juste "" si nous appelons insmod file.elf sans plus d'arguments.

init_module est fournie ci-dessus par:

#ifdef __UCLIBC__
extern int init_module(void *module, unsigned long len, const char *options);
extern int delete_module(const char *module, unsigned int flags);
#else
# include <sys/syscall.h>
# define init_module(mod, len, opts) syscall(__NR_init_module, mod, len, opts)
# define delete_module(mod, flags) syscall(__NR_delete_module, mod, flags)
#endif

ulibc est un intégré de la libc mise en œuvre, et il semble init_module.

Si elle ne l'est pas, je pense que la glibc est supposé, mais comme man init_module dit:

La init_module() de l'appel système n'est pas pris en charge par la glibc. Aucune déclaration n'est fourni dans la glibc, en-têtes, mais, par un caprice de l'histoire, de la glibc ne l'exportation de l'ABI pour
cet appel système. Par conséquent, afin de les employer cet appel système, il suffit de déclarer manuellement l'interface de votre code; alternativement, vous pouvez appeler
le système d'appel à l'aide de syscall(2).

BusyBox sagement en résulte que des conseils et utilise syscall, qui glibc fournit, et qui propose une API C pour les appels-système.

OriginalL'auteur

Je voudrais recommander l'utilisation de system() quelque démon code qui s'exécute avec les privilèges de root car il est relativement facile à exploiter à partir d'un point de vue sécurité. modprobe et rmmod sont, en effet, les bons outils pour le travail. Cependant, il faudrait être un peu plus propre et beaucoup plus sûr d'utiliser un explicite fork() + exec() de les invoquer.

OriginalL'auteur

Je ne suis pas sûr qu'il y a un nettoyant façon que system.

Mais pour sûr, si vous voulez charger/décharger les modules à partir de votre espace utilisateur démon, alors vous vous forcez à exécuter le démon en tant que root*, qui ne peut être considéré comme sécurisé.

*: ou vous pouvez ajouter les commandements explicites dans le fichier sudoers, mais cela va être un cauchemar à gérer lorsque vous déployez votre application.

OriginalL'auteur