Выполнить / вызвать программу пользовательского пространства и получить ее pid из модуля ядра

Я проверил API-интерфейсы ядра, часть 1: вызов приложений из пространства пользователя из ядра и выполнение функции пространства пользователя из пространства ядра - переполнение стека - и вот небольшой модуль ядра, callmodule.c, демонстрируя, что:

// http://people.ee.ethz.ch/~arkeller/linux/code/usermodehelper.c

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/proc_fs.h>
#include <asm/uaccess.h>

static int __init callmodule_init(void)
{
    int ret = 0;
    char userprog[] = "/path/to/mytest";
    char *argv[] = {userprog, "2", NULL };
    char *envp[] = {"HOME=/", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL };

    printk("callmodule: init %s\n", userprog);
    /* last parameter: 1 -> wait until execution has finished, 0 go ahead without waiting*/
    /* returns 0 if usermode process was started successfully, errorvalue otherwise*/
    /* no possiblity to get return value of usermode process*/
    ret = call_usermodehelper(userprog, argv, envp, UMH_WAIT_EXEC);
    if (ret != 0)
        printk("error in call to usermodehelper: %i\n", ret);
    else
        printk("everything all right\n");
        return 0;
}

static void __exit callmodule_exit(void)
{
    printk("callmodule: exit\n");
}

module_init(callmodule_init);
module_exit(callmodule_exit);
MODULE_LICENSE("GPL");

... с Makefile:

obj-m += callmodule.o

all:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Когда я запускаю это через sudo insmod ./callmodule.ko && sudo rmmod callmodule Я вхожу в /var/log/syslog:

Feb 10 00:42:45 mypc kernel: [71455.260355] callmodule: init /path/to/mytest
Feb 10 00:42:45 mypc kernel: [71455.261218] everything all right
Feb 10 00:42:45 mypc kernel: [71455.286131] callmodule: exit

... что, очевидно, означает, что все прошло хорошо. (Использование Linux 2.6.38-16-generiC#67-Ubuntu SMP)

Мой вопрос - как я могу получить PID процесса, созданного из модуля ядра? Есть ли подобный процесс, кроме call_usermodehelper, что позволит мне создать экземпляр процесса пользовательского пространства в пространстве ядра и получить его pid?


Обратите внимание, что это может быть невозможно использовать call_usermodehelper и получить экземпляр процесса PID:

Re: пид call_usermodehelper? - Linux Kernel Newbies

Я хочу создать процесс пространства пользователя из модуля ядра и иметь возможность убивать его, посылать ему сигналы и т. Д.

можно узнать его пид?

Нет, ты не можешь. Но поскольку внутри реализации pid известен, патч, который делает его доступным, не будет слишком сложным (обратите внимание, что ошибки всегда отрицательны в ядре, а pids положительны, ограничены 2**16). Вы должны будете изменить всех вызывающих абонентов, которые ожидают 0 в случае успеха.

Я немного покопался в источниках, и кажется, что в конечном итоге есть цепочка вызовов: call_usermodehelper -> call_usermodehelper_setup -> __call_usermodehelper, который выглядит как:

static void __call_usermodehelper(struct work_struct *work)
{
    struct subprocess_info *sub_info =
        container_of(work, struct subprocess_info, work);
    // ...
    if (wait == UMH_WAIT_PROC)
        pid = kernel_thread(wait_for_helper, sub_info,
                    CLONE_FS | CLONE_FILES | SIGCHLD);
    else
        pid = kernel_thread(____call_usermodehelper, sub_info,
                    CLONE_VFORK | SIGCHLD);
...

... поэтому используется PID потока ядра, но он нигде не сохраняется; кроме того, ни work_struct ни subprocess_info иметь pid поле (task_struct делает, но здесь ничего не похоже task_struct). Запись этого pid потребует изменения исходных кодов ядра - и, поскольку я хотел бы избежать этого, это причина, почему я также заинтересован в подходах, отличных от call_usermodehelper...

2 ответа

Предварительный ответ из моего понимания реализации в kmod.c.

Если вы посмотрите на код call_usermodehelper вы увидите это звонки call_usermodehelper_setup а потом call_usermodehelper_exec,

call_usermodehelper_setup принимает в качестве параметра функцию инициализации, которая будет выполнена непосредственно перед do_execve, Я считаю ценность current когда функция init будет выполнена, вы получите task_struct пользовательского процесса.

Итак, чтобы получить pid, вам необходимо:

  1. Скопируйте реализацию call_usermodehelper в вашем коде.
  2. Определите функцию инициализации, которую вы передадите в качестве параметра call_usermodehelper_setup,
  3. В функции init извлекает текущий task_struct и в свою очередь PID.

Ну, это было утомительно... Ниже приведен довольно хакерский способ добиться этого, по крайней мере, на моей платформе, как callmodule.c (можно использовать тот же Makefile, что и выше). Поскольку я не могу поверить, что именно так это и должно быть сделано, более правильные ответы все еще приветствуются (надеюсь, также, с примером кода, который я мог бы протестировать). Но, по крайней мере, он выполняет работу только как модуль ядра - без необходимости исправления самого ядра - для версии 2.6.38, что было для меня очень важно.

По сути, я скопировал все функции (переименованные с суффиксом "B") до точки, где доступен PID. Тогда я использую копию subprocess_info с дополнительным полем для его сохранения (хотя это не является строго необходимым: чтобы не связываться с сигнатурами функций относительно возвращаемого значения, я все равно должен сохранить pid как глобальную переменную; оставил его как упражнение). Теперь, когда я бегу sudo insmod ./callmodule.ko && sudo rmmod callmodule, в /var/log/syslog Я получил:

Feb 10 18:53:02 mypc kernel: [ 2942.891886] callmodule: > init /path/to/mytest
Feb 10 18:53:02 mypc kernel: [ 2942.891912] callmodule: symbol @ 0xc1065b60 is wait_for_helper+0x0/0xb0
Feb 10 18:53:02 mypc kernel: [ 2942.891923] callmodule: symbol @ 0xc1065ed0 is ____call_usermodehelper+0x0/0x90
Feb 10 18:53:02 mypc kernel: [ 2942.891932] callmodule:a: pid 0
Feb 10 18:53:02 mypc kernel: [ 2942.891937] callmodule:b: pid 0
Feb 10 18:53:02 mypc kernel: [ 2942.893491] callmodule: : pid 23306
Feb 10 18:53:02 mypc kernel: [ 2942.894474] callmodule:c: pid 23306
Feb 10 18:53:02 mypc kernel: [ 2942.894483] callmodule: everything all right; pid 23306
Feb 10 18:53:02 mypc kernel: [ 2942.894494] callmodule: pid task a: ec401940 c: mytest p: [23306] s: runnable
Feb 10 18:53:02 mypc kernel: [ 2942.894502] callmodule: parent task a: f40aa5e0 c: kworker/u:1 p: [14] s: stopped
Feb 10 18:53:02 mypc kernel: [ 2942.894510] callmodule: - mytest [23306]
Feb 10 18:53:02 mypc kernel: [ 2942.918500] callmodule: < exit

Одна из неприятных проблем здесь заключается в том, что как только вы начинаете копировать функции, в определенное время вы попадаете в точку, где используются функции ядра, которые не экспортируются, как в этом случае wait_for_helper, То, что я сделал, было в основном смотреть в /proc/kallsyms (Помните sudo!) чтобы получить абсолютные адреса например wait_for_helperзатем жестко запрограммированные в модуле ядра указатели на функции - похоже, работает. Другая проблема заключается в том, что функции в исходном коде ядра ссылаются на enum umh_wait, который не может быть использован в качестве аргумента из модуля (их нужно просто преобразовать для использования int вместо).

Таким образом, модуль запускает процесс пользовательского пространства, получает PID (отмечая, что " то, что ядро ​​называет PID, на самом деле являются идентификаторами потоков уровня ядра (часто называемыми TID) ... Что считается PID в смысле POSIX" процесс ", с другой стороны, называется "идентификатором группы потоков" или "TGID" в ядре. "), получает соответствующий task_struct и его родитель, и пытается перечислить все дочерние элементы родителя и самого порожденного процесса. Итак, я вижу, что kworker/u:1 обычно является родителем, и у него нет других детей, кроме mytest - и с тех пор mytest это очень просто (в моем случае это всего лишь один файл записи на диск), он не создает собственных потоков, поэтому он также не имеет дочерних элементов.

Я столкнулся с несколькими Oopses, которые потребовали перезагрузки - я думаю, что они решены сейчас, но на всякий случай, caveat emptor.

Здесь callmodule.c код (с некоторыми примечаниями / ссылками в конце):

// callmodule.c with pid, url: https://stackru.com/questions/21668727/

#include <linux/module.h>
#include <linux/slab.h> //kzalloc
#include <linux/syscalls.h> // SIGCHLD, ... sys_wait4, ...
#include <linux/kallsyms.h> // kallsyms_lookup, print_symbol

// global variable - to avoid intervening too much in the return of call_usermodehelperB:
static int callmodule_pid;

// >>>>>>>>>>>>>>>>>>>>>>

// modified kernel functions - taken from
// http://lxr.missinglinkelectronics.com/linux+v2.6.38/+save=include/linux/kmod.h
// http://lxr.linux.no/linux+v2.6.38/+save=kernel/kmod.c

// define a modified struct (with extra pid field) here:
struct subprocess_infoB {
    struct work_struct work;
    struct completion *complete;
    char *path;
    char **argv;
    char **envp;
    int wait; //enum umh_wait wait;
    int retval;
    int (*init)(struct subprocess_info *info);
    void (*cleanup)(struct subprocess_info *info);
    void *data;
  pid_t pid;
};

// forward declare:
struct subprocess_infoB *call_usermodehelper_setupB(char *path, char **argv,
                          char **envp, gfp_t gfp_mask);

static inline int
call_usermodehelper_fnsB(char *path, char **argv, char **envp,
            int wait, //enum umh_wait wait,
            int (*init)(struct subprocess_info *info),
            void (*cleanup)(struct subprocess_info *), void *data)
{
    struct subprocess_info *info;
    struct subprocess_infoB *infoB;
    gfp_t gfp_mask = (wait == UMH_NO_WAIT) ? GFP_ATOMIC : GFP_KERNEL;
  int ret;

  populate_rootfs_wait(); // is in linux-headers-2.6.38-16-generic/include/linux/kmod.h

    infoB = call_usermodehelper_setupB(path, argv, envp, gfp_mask);
  printk(KBUILD_MODNAME ":a: pid %d\n", infoB->pid);
  info = (struct subprocess_info *) infoB;

    if (info == NULL)
        return -ENOMEM;

    call_usermodehelper_setfns(info, init, cleanup, data);
  printk(KBUILD_MODNAME ":b: pid %d\n", infoB->pid);

  // this must be called first, before infoB->pid is populated (by __call_usermodehelperB):
  ret = call_usermodehelper_exec(info, wait);

  // assign global pid here, so rest of the code has it:
  callmodule_pid = infoB->pid;
  printk(KBUILD_MODNAME ":c: pid %d\n", callmodule_pid);

    return ret;
}

static inline int
call_usermodehelperB(char *path, char **argv, char **envp, int wait) //enum umh_wait wait)
{
    return call_usermodehelper_fnsB(path, argv, envp, wait,
                       NULL, NULL, NULL);
}

/* This is run by khelper thread  */
static void __call_usermodehelperB(struct work_struct *work)
{
    struct subprocess_infoB *sub_infoB =
        container_of(work, struct subprocess_infoB, work);
    int wait = sub_infoB->wait; // enum umh_wait wait = sub_info->wait;
    pid_t pid;
    struct subprocess_info *sub_info;
  // hack - declare function pointers, to use for wait_for_helper/____call_usermodehelper
  int (*ptrwait_for_helper)(void *data);
  int (*ptr____call_usermodehelper)(void *data);
  // assign function pointers to verbatim addresses as obtained from /proc/kallsyms
  ptrwait_for_helper = (void *)0xc1065b60;
  ptr____call_usermodehelper = (void *)0xc1065ed0;

  sub_info = (struct subprocess_info *)sub_infoB;

    /* CLONE_VFORK: wait until the usermode helper has execve'd
     * successfully We need the data structures to stay around
     * until that is done.  */
    if (wait == UMH_WAIT_PROC)
        pid = kernel_thread((*ptrwait_for_helper), sub_info, //(wait_for_helper, sub_info,
                    CLONE_FS | CLONE_FILES | SIGCHLD);
    else
        pid = kernel_thread((*ptr____call_usermodehelper), sub_info, //(____call_usermodehelper, sub_info,
                    CLONE_VFORK | SIGCHLD);

  printk(KBUILD_MODNAME ": : pid %d\n", pid);
  // grab and save the pid here:
  sub_infoB->pid = pid;
    switch (wait) {
    case UMH_NO_WAIT:
        call_usermodehelper_freeinfo(sub_info);
        break;

    case UMH_WAIT_PROC:
        if (pid > 0)
            break;
        /* FALLTHROUGH */
    case UMH_WAIT_EXEC:
        if (pid < 0)
            sub_info->retval = pid;
        complete(sub_info->complete);
    }
}

/**
 * call_usermodehelper_setup - prepare to call a usermode helper
 */
struct subprocess_infoB *call_usermodehelper_setupB(char *path, char **argv,
                          char **envp, gfp_t gfp_mask)
{
    struct subprocess_infoB *sub_infoB;
    sub_infoB = kzalloc(sizeof(struct subprocess_infoB), gfp_mask);
    if (!sub_infoB)
        goto out;

    INIT_WORK(&sub_infoB->work, __call_usermodehelperB);
    sub_infoB->path = path;
    sub_infoB->argv = argv;
    sub_infoB->envp = envp;
  out:
    return sub_infoB;
}

// <<<<<<<<<<<<<<<<<<<<<<

static int __init callmodule_init(void)
{
    int ret = 0;
  char userprog[] = "/path/to/mytest";
    char *argv[] = {userprog, "2", NULL };
    char *envp[] = {"HOME=/", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL };
  struct task_struct *p;
  struct task_struct *par;
  struct task_struct *pc;
  struct list_head *children_list_head;
  struct list_head *cchildren_list_head;
  char *state_str;

    printk(KBUILD_MODNAME ": > init %s\n", userprog);
    /* last parameter: 1 -> wait until execution has finished, 0 go ahead without waiting*/
    /* returns 0 if usermode process was started successfully, errorvalue otherwise*/
    /* no possiblity to get return value of usermode process*/
  // note - only one argument allowed for print_symbol
  print_symbol(KBUILD_MODNAME ": symbol @ 0xc1065b60 is %s\n", 0xc1065b60); // shows wait_for_helper+0x0/0xb0
  print_symbol(KBUILD_MODNAME ": symbol @ 0xc1065ed0 is %s\n", 0xc1065ed0); // shows ____call_usermodehelper+0x0/0x90
    ret = call_usermodehelperB(userprog, argv, envp, UMH_WAIT_EXEC);
    if (ret != 0)
        printk(KBUILD_MODNAME ": error in call to usermodehelper: %i\n", ret);
    else
        printk(KBUILD_MODNAME ": everything all right; pid %d\n", callmodule_pid);
  // find the task:
  // note: sometimes p may end up being NULL here, causing kernel oops -
  // just exit prematurely in that case
  rcu_read_lock();
  p = pid_task(find_vpid(callmodule_pid), PIDTYPE_PID);
  rcu_read_unlock();
  if (p == NULL) {
    printk(KBUILD_MODNAME ": p is NULL - exiting\n");
    return 0;
  }
  // p->comm should be the command/program name (as per userprog)
  // (out here that task is typically in runnable state)
  state_str = (p->state==-1)?"unrunnable":((p->state==0)?"runnable":"stopped");
  printk(KBUILD_MODNAME ": pid task a: %p c: %s p: [%d] s: %s\n",
    p, p->comm, p->pid, state_str);

  // find parent task:
  // parent task could typically be: c: kworker/u:1 p: [14] s: stopped
  par = p->parent;
  if (par == NULL) {
    printk(KBUILD_MODNAME ": par is NULL - exiting\n");
    return 0;
  }
  state_str = (par->state==-1)?"unrunnable":((par->state==0)?"runnable":"stopped");
  printk(KBUILD_MODNAME ": parent task a: %p c: %s p: [%d] s: %s\n",
    par, par->comm, par->pid, state_str);

  // iterate through parent's (and our task's) child processes:
  rcu_read_lock(); // read_lock(&tasklist_lock);
  list_for_each(children_list_head, &par->children){
    p = list_entry(children_list_head, struct task_struct, sibling);
    printk(KBUILD_MODNAME ": - %s [%d] \n", p->comm, p->pid);
    // note: trying to print "%p",p here results with oops/segfault:
    // printk(KBUILD_MODNAME ": - %s [%d] %p\n", p->comm, p->pid, p);
    if (p->pid == callmodule_pid) {
      list_for_each(cchildren_list_head, &p->children){
        pc = list_entry(cchildren_list_head, struct task_struct, sibling);
        printk(KBUILD_MODNAME ": - - %s [%d] \n", pc->comm, pc->pid);
      }
    }
  }
  rcu_read_unlock(); //~ read_unlock(&tasklist_lock);

  return 0;
}

static void __exit callmodule_exit(void)
{
    printk(KBUILD_MODNAME ": < exit\n");
}

module_init(callmodule_init);
module_exit(callmodule_exit);
MODULE_LICENSE("GPL");


/*

NOTES:

  // assign function pointers to verbatim addresses as obtained from /proc/kallsyms:
  // ( cast to void* to avoid "warning: assignment makes pointer from integer without a cast",
  // see also https://stackru.com/questions/3941793/what-is-guaranteed-about-the-size-of-a-function-pointer )

// $ sudo grep 'wait_for_helper\|____call_usermodehelper' /proc/kallsyms
// c1065b60 t wait_for_helper
// c1065ed0 t ____call_usermodehelper
// protos:
// static int wait_for_helper(void *data)
// static int ____call_usermodehelper(void *data)
// see also:
// http://www.linuxforu.com/2012/02/function-pointers-and-callbacks-in-c-an-odyssey/


// from include/linux/kmod.h:

//~ enum umh_wait {
    //~ UMH_NO_WAIT = -1,   /* don't wait at all * /
    //~ UMH_WAIT_EXEC = 0,  /* wait for the exec, but not the process * /
    //~ UMH_WAIT_PROC = 1,  /* wait for the process to complete * /
//~ };

// however, note:
// /usr/src/linux-headers-2.6.38-16-generic/include/linux/kmod.h:
// #define UMH_NO_WAIT  0 ; UMH_WAIT_EXEC   1 ; UMH_WAIT_PROC   2 ; UMH_KILLABLE    4 !
// those defines end up here, regardless of the enum definition above
// (NB: 0,1,2,4 enumeration starts from kmod.h?v=3.4 on lxr.free-electrons.com !)
// also, note, in "generic" include/, prototypes of call_usermodehelper(_fns)
// use int wait, and not enum umh_wait wait ...

// seems these cannot be used from a module, nonetheless:
//~ extern int wait_for_helper(void *data);
//~ extern int ____call_usermodehelper(void *data);
// we probably would have to (via http://www.linuxconsulting.ro/pidwatcher/)
// edit /usr/src/linux/kernel/ksyms.c and add:
//EXPORT_SYMBOL(wait_for_helper);
// but that is kernel re-compilation...

// https://stackru.com/questions/19360298/triggering-user-space-with-kernel
// You should not be using PIDs to identify processes within the kernel. The process can exit and a different process re-use that PID. Instead, you should be using a pointer to the task_struct for the process (rather than storing current->pid at registration time, just store current)

# reports task name from the pid (pid_task(find_get_pid(..)):
http://tuxthink.blogspot.dk/2012/07/module-to-find-task-from-its-pid.html

  // find the task:
    //~ rcu_read_lock();
  // uprobes uses this - but find_task_by_pid is not exported for modules:
    //~ p = find_task_by_pid(callmodule_pid);
    //~ if (p)
        //~ get_task_struct(p);
    //~ rcu_read_unlock();
  // see: [http://www.gossamer-threads.com/lists/linux/kernel/1260996 find_task_by_pid() problem | Linux | Kernel]

  // https://stackru.com/questions/18408766/make-a-system-call-to-get-list-of-processes
  // this macro loops through *all* processes; our callmodule_pid should be listed by it
  //~ for_each_process(p)
    //~ pr_info("%s [%d]\n", p->comm, p->pid);

  // [https://lists.debian.org/debian-devel/2008/05/msg00034.html Re: problems for making kernel module]
  // note - WARNING: "tasklist_lock" ... undefined; because tasklist_lock removed in 2.6.1*:
  // "tasklist_lock protects the kernel internal task list.  Modules have no business looking at it";
  // https://stackru.com/questions/13002444/list-all-threads-within-the-current-process
  // "all methods that loop over the task lists need to be wrapped in rcu_read_lock(); / rcu_read_unlock(); to be correct."
  // https://stackru.com/questions/19208487/kernel-module-that-iterates-over-all-tasks-using-depth-first-tree
  // https://stackru.com/questions/5728592/how-can-i-get-the-children-process-list-in-kernel-code
  // https://stackru.com/questions/1446239/traversing-task-struct-children-in-linux-kernel
  // https://stackru.com/questions/8207160/kernel-how-to-iterate-the-children-of-the-current-process
  // https://stackru.com/questions/10262017/linux-kernel-list-list-head-init-vs-init-list-head
  // https://stackru.com/questions/16230524/explain-list-for-each-entry-and-list-for-each-entry-safe "list_entry is just an alias for container_of"

*/
Другие вопросы по тегам