2017-09-09 07:17:08 +08:00
|
|
|
#ifndef __LINUX_UMH_H__
|
|
|
|
|
#define __LINUX_UMH_H__
|
|
|
|
|
|
|
|
|
|
#include <linux/gfp.h>
|
|
|
|
|
#include <linux/stddef.h>
|
|
|
|
|
#include <linux/errno.h>
|
|
|
|
|
#include <linux/compiler.h>
|
|
|
|
|
#include <linux/workqueue.h>
|
|
|
|
|
#include <linux/sysctl.h>
|
|
|
|
|
|
|
|
|
|
struct cred;
|
|
|
|
|
struct file;
|
|
|
|
|
|
|
|
|
|
#define UMH_NO_WAIT 0 /* don't wait at all */
|
|
|
|
|
#define UMH_WAIT_EXEC 1 /* wait for the exec, but not the process */
|
|
|
|
|
#define UMH_WAIT_PROC 2 /* wait for the process to complete */
|
|
|
|
|
#define UMH_KILLABLE 4 /* wait for EXEC/PROC killable */
|
|
|
|
|
|
|
|
|
|
struct subprocess_info {
|
|
|
|
|
struct work_struct work;
|
|
|
|
|
struct completion *complete;
|
|
|
|
|
const char *path;
|
|
|
|
|
char **argv;
|
|
|
|
|
char **envp;
|
umh: introduce fork_usermode_blob() helper
Introduce helper:
int fork_usermode_blob(void *data, size_t len, struct umh_info *info);
struct umh_info {
struct file *pipe_to_umh;
struct file *pipe_from_umh;
pid_t pid;
};
that GPLed kernel modules (signed or unsigned) can use it to execute part
of its own data as swappable user mode process.
The kernel will do:
- allocate a unique file in tmpfs
- populate that file with [data, data + len] bytes
- user-mode-helper code will do_execve that file and, before the process
starts, the kernel will create two unix pipes for bidirectional
communication between kernel module and umh
- close tmpfs file, effectively deleting it
- the fork_usermode_blob will return zero on success and populate
'struct umh_info' with two unix pipes and the pid of the user process
As the first step in the development of the bpfilter project
the fork_usermode_blob() helper is introduced to allow user mode code
to be invoked from a kernel module. The idea is that user mode code plus
normal kernel module code are built as part of the kernel build
and installed as traditional kernel module into distro specified location,
such that from a distribution point of view, there is
no difference between regular kernel modules and kernel modules + umh code.
Such modules can be signed, modprobed, rmmod, etc. The use of this new helper
by a kernel module doesn't make it any special from kernel and user space
tooling point of view.
Such approach enables kernel to delegate functionality traditionally done
by the kernel modules into the user space processes (either root or !root) and
reduces security attack surface of the new code. The buggy umh code would crash
the user process, but not the kernel. Another advantage is that umh code
of the kernel module can be debugged and tested out of user space
(e.g. opening the possibility to run clang sanitizers, fuzzers or
user space test suites on the umh code).
In case of the bpfilter project such architecture allows complex control plane
to be done in the user space while bpf based data plane stays in the kernel.
Since umh can crash, can be oom-ed by the kernel, killed by the admin,
the kernel module that uses them (like bpfilter) needs to manage life
time of umh on its own via two unix pipes and the pid of umh.
The exit code of such kernel module should kill the umh it started,
so that rmmod of the kernel module will cleanup the corresponding umh.
Just like if the kernel module does kmalloc() it should kfree() it
in the exit code.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-22 10:22:29 +08:00
|
|
|
struct file *file;
|
2017-09-09 07:17:08 +08:00
|
|
|
int wait;
|
|
|
|
|
int retval;
|
umh: introduce fork_usermode_blob() helper
Introduce helper:
int fork_usermode_blob(void *data, size_t len, struct umh_info *info);
struct umh_info {
struct file *pipe_to_umh;
struct file *pipe_from_umh;
pid_t pid;
};
that GPLed kernel modules (signed or unsigned) can use it to execute part
of its own data as swappable user mode process.
The kernel will do:
- allocate a unique file in tmpfs
- populate that file with [data, data + len] bytes
- user-mode-helper code will do_execve that file and, before the process
starts, the kernel will create two unix pipes for bidirectional
communication between kernel module and umh
- close tmpfs file, effectively deleting it
- the fork_usermode_blob will return zero on success and populate
'struct umh_info' with two unix pipes and the pid of the user process
As the first step in the development of the bpfilter project
the fork_usermode_blob() helper is introduced to allow user mode code
to be invoked from a kernel module. The idea is that user mode code plus
normal kernel module code are built as part of the kernel build
and installed as traditional kernel module into distro specified location,
such that from a distribution point of view, there is
no difference between regular kernel modules and kernel modules + umh code.
Such modules can be signed, modprobed, rmmod, etc. The use of this new helper
by a kernel module doesn't make it any special from kernel and user space
tooling point of view.
Such approach enables kernel to delegate functionality traditionally done
by the kernel modules into the user space processes (either root or !root) and
reduces security attack surface of the new code. The buggy umh code would crash
the user process, but not the kernel. Another advantage is that umh code
of the kernel module can be debugged and tested out of user space
(e.g. opening the possibility to run clang sanitizers, fuzzers or
user space test suites on the umh code).
In case of the bpfilter project such architecture allows complex control plane
to be done in the user space while bpf based data plane stays in the kernel.
Since umh can crash, can be oom-ed by the kernel, killed by the admin,
the kernel module that uses them (like bpfilter) needs to manage life
time of umh on its own via two unix pipes and the pid of umh.
The exit code of such kernel module should kill the umh it started,
so that rmmod of the kernel module will cleanup the corresponding umh.
Just like if the kernel module does kmalloc() it should kfree() it
in the exit code.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-22 10:22:29 +08:00
|
|
|
pid_t pid;
|
2017-09-09 07:17:08 +08:00
|
|
|
int (*init)(struct subprocess_info *info, struct cred *new);
|
|
|
|
|
void (*cleanup)(struct subprocess_info *info);
|
|
|
|
|
void *data;
|
|
|
|
|
} __randomize_layout;
|
|
|
|
|
|
|
|
|
|
extern int
|
|
|
|
|
call_usermodehelper(const char *path, char **argv, char **envp, int wait);
|
|
|
|
|
|
|
|
|
|
extern struct subprocess_info *
|
|
|
|
|
call_usermodehelper_setup(const char *path, char **argv, char **envp,
|
|
|
|
|
gfp_t gfp_mask,
|
|
|
|
|
int (*init)(struct subprocess_info *info, struct cred *new),
|
|
|
|
|
void (*cleanup)(struct subprocess_info *), void *data);
|
|
|
|
|
|
umh: introduce fork_usermode_blob() helper
Introduce helper:
int fork_usermode_blob(void *data, size_t len, struct umh_info *info);
struct umh_info {
struct file *pipe_to_umh;
struct file *pipe_from_umh;
pid_t pid;
};
that GPLed kernel modules (signed or unsigned) can use it to execute part
of its own data as swappable user mode process.
The kernel will do:
- allocate a unique file in tmpfs
- populate that file with [data, data + len] bytes
- user-mode-helper code will do_execve that file and, before the process
starts, the kernel will create two unix pipes for bidirectional
communication between kernel module and umh
- close tmpfs file, effectively deleting it
- the fork_usermode_blob will return zero on success and populate
'struct umh_info' with two unix pipes and the pid of the user process
As the first step in the development of the bpfilter project
the fork_usermode_blob() helper is introduced to allow user mode code
to be invoked from a kernel module. The idea is that user mode code plus
normal kernel module code are built as part of the kernel build
and installed as traditional kernel module into distro specified location,
such that from a distribution point of view, there is
no difference between regular kernel modules and kernel modules + umh code.
Such modules can be signed, modprobed, rmmod, etc. The use of this new helper
by a kernel module doesn't make it any special from kernel and user space
tooling point of view.
Such approach enables kernel to delegate functionality traditionally done
by the kernel modules into the user space processes (either root or !root) and
reduces security attack surface of the new code. The buggy umh code would crash
the user process, but not the kernel. Another advantage is that umh code
of the kernel module can be debugged and tested out of user space
(e.g. opening the possibility to run clang sanitizers, fuzzers or
user space test suites on the umh code).
In case of the bpfilter project such architecture allows complex control plane
to be done in the user space while bpf based data plane stays in the kernel.
Since umh can crash, can be oom-ed by the kernel, killed by the admin,
the kernel module that uses them (like bpfilter) needs to manage life
time of umh on its own via two unix pipes and the pid of umh.
The exit code of such kernel module should kill the umh it started,
so that rmmod of the kernel module will cleanup the corresponding umh.
Just like if the kernel module does kmalloc() it should kfree() it
in the exit code.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-22 10:22:29 +08:00
|
|
|
struct subprocess_info *call_usermodehelper_setup_file(struct file *file,
|
|
|
|
|
int (*init)(struct subprocess_info *info, struct cred *new),
|
|
|
|
|
void (*cleanup)(struct subprocess_info *), void *data);
|
|
|
|
|
struct umh_info {
|
2018-10-21 01:39:56 +08:00
|
|
|
const char *cmdline;
|
umh: introduce fork_usermode_blob() helper
Introduce helper:
int fork_usermode_blob(void *data, size_t len, struct umh_info *info);
struct umh_info {
struct file *pipe_to_umh;
struct file *pipe_from_umh;
pid_t pid;
};
that GPLed kernel modules (signed or unsigned) can use it to execute part
of its own data as swappable user mode process.
The kernel will do:
- allocate a unique file in tmpfs
- populate that file with [data, data + len] bytes
- user-mode-helper code will do_execve that file and, before the process
starts, the kernel will create two unix pipes for bidirectional
communication between kernel module and umh
- close tmpfs file, effectively deleting it
- the fork_usermode_blob will return zero on success and populate
'struct umh_info' with two unix pipes and the pid of the user process
As the first step in the development of the bpfilter project
the fork_usermode_blob() helper is introduced to allow user mode code
to be invoked from a kernel module. The idea is that user mode code plus
normal kernel module code are built as part of the kernel build
and installed as traditional kernel module into distro specified location,
such that from a distribution point of view, there is
no difference between regular kernel modules and kernel modules + umh code.
Such modules can be signed, modprobed, rmmod, etc. The use of this new helper
by a kernel module doesn't make it any special from kernel and user space
tooling point of view.
Such approach enables kernel to delegate functionality traditionally done
by the kernel modules into the user space processes (either root or !root) and
reduces security attack surface of the new code. The buggy umh code would crash
the user process, but not the kernel. Another advantage is that umh code
of the kernel module can be debugged and tested out of user space
(e.g. opening the possibility to run clang sanitizers, fuzzers or
user space test suites on the umh code).
In case of the bpfilter project such architecture allows complex control plane
to be done in the user space while bpf based data plane stays in the kernel.
Since umh can crash, can be oom-ed by the kernel, killed by the admin,
the kernel module that uses them (like bpfilter) needs to manage life
time of umh on its own via two unix pipes and the pid of umh.
The exit code of such kernel module should kill the umh it started,
so that rmmod of the kernel module will cleanup the corresponding umh.
Just like if the kernel module does kmalloc() it should kfree() it
in the exit code.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-22 10:22:29 +08:00
|
|
|
struct file *pipe_to_umh;
|
|
|
|
|
struct file *pipe_from_umh;
|
|
|
|
|
pid_t pid;
|
|
|
|
|
};
|
|
|
|
|
int fork_usermode_blob(void *data, size_t len, struct umh_info *info);
|
|
|
|
|
|
2017-09-09 07:17:08 +08:00
|
|
|
extern int
|
|
|
|
|
call_usermodehelper_exec(struct subprocess_info *info, int wait);
|
|
|
|
|
|
|
|
|
|
extern struct ctl_table usermodehelper_table[];
|
|
|
|
|
|
|
|
|
|
enum umh_disable_depth {
|
|
|
|
|
UMH_ENABLED = 0,
|
|
|
|
|
UMH_FREEZING,
|
|
|
|
|
UMH_DISABLED,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
extern int __usermodehelper_disable(enum umh_disable_depth depth);
|
|
|
|
|
extern void __usermodehelper_set_disable_depth(enum umh_disable_depth depth);
|
|
|
|
|
|
|
|
|
|
static inline int usermodehelper_disable(void)
|
|
|
|
|
{
|
|
|
|
|
return __usermodehelper_disable(UMH_DISABLED);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void usermodehelper_enable(void)
|
|
|
|
|
{
|
|
|
|
|
__usermodehelper_set_disable_depth(UMH_ENABLED);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern int usermodehelper_read_trylock(void);
|
|
|
|
|
extern long usermodehelper_read_lock_wait(long timeout);
|
|
|
|
|
extern void usermodehelper_read_unlock(void);
|
|
|
|
|
|
|
|
|
|
#endif /* __LINUX_UMH_H__ */
|
