1INIT_MODULE(2) Linux Programmer's Manual INIT_MODULE(2)
2
6 init_module, finit_module - load a kernel module
7
9 int init_module(void *module_image, unsigned long len,
10 const char *param_values);
11 int finit_module(int fd, const char *param_values,
13 int flags);
14 Note: There are no glibc wrappers for these system calls; see NOTES.
16
18 init_module() loads an ELF image into kernel space, performs any neces‐
19 sary symbol relocations, initializes module parameters to values pro‐
20 vided by the caller, and then runs the module's init function. This
21 system call requires privilege.
22 The module_image argument points to a buffer containing the binary
24 image to be loaded; len specifies the size of that buffer. The module
25 image should be a valid ELF image, built for the running kernel.
26 The param_values argument is a string containing space-delimited speci‐
28 fications of the values for module parameters (defined inside the mod‐
29 ule using module_param() and module_param_array()). The kernel parses
30 this string and initializes the specified parameters. Each of the
31 parameter specifications has the form:
32 name[=value[,value...]]
34 The parameter name is one of those defined within the module using mod‐
36 ule_param() (see the Linux kernel source file include/linux/mod‐
37 uleparam.h). The parameter value is optional in the case of bool and
38 invbool parameters. Values for array parameters are specified as a
39 comma-separated list.
40 finit_module()
42 The finit_module() system call is like init_module(), but reads the
43 module to be loaded from the file descriptor fd. It is useful when the
44 authenticity of a kernel module can be determined from its location in
45 the file system; in cases where that is possible, the overhead of using
46 cryptographically signed modules to determine the authenticity of a
47 module can be avoided. The param_values argument is as for init_mod‐
48 ule().
49 The flags argument modifies the operation of finit_module(). It is a
51 bit mask value created by ORing together zero or more of the following
52 flags:
53 MODULE_INIT_IGNORE_MODVERSIONS
55 Ignore symbol version hashes.
56 MODULE_INIT_IGNORE_VERMAGIC
58 Ignore kernel version magic.
59 There are some safety checks built into a module to ensure that it
61 matches the kernel against which it is loaded. These checks are
62 recorded when the module is built and verified when the module is
63 loaded. First, the module records a "vermagic" string containing the
64 kernel version number and prominent features (such as the CPU type).
65 Second, if the module was built with the CONFIG_MODVERSIONS configura‐
66 tion option enabled, a version hash is recorded for each symbol the
67 module uses. This hash is based on the types of the arguments and
68 return value for the function named by the symbol. In this case, the
69 kernel version number within the "vermagic" string is ignored, as the
70 symbol version hashes are assumed to be sufficiently reliable.
71 Using the MODULE_INIT_IGNORE_VERMAGIC flag indicates that the "ver‐
73 magic" string is to be ignored, and the MODULE_INIT_IGNORE_MODVERSIONS
74 flag indicates that the symbol version hashes are to be ignored. If
75 the kernel is built to permit forced loading (i.e., configured with
76 CONFIG_MODULE_FORCE_LOAD), then loading will continue, otherwise it
77 will fail with ENOEXEC as expected for malformed modules.
78
80 On success, these system calls return 0. On error, -1 is returned and
81 errno is set appropriately.
82
84 EBADMSG (since Linux 3.7)
85 Module signature is misformatted.
86 EBUSY Timeout while trying to resolve a symbol reference by this mod‐
88 ule.
89 EFAULT An address argument referred to a location that is outside the
91 process's accessible address space.
92 ENOKEY (since Linux 3.7)
94 Module signature is invalid or the kernel does not have a key
95 for this module. This error is returned only if the kernel was
96 configured with CONFIG_MODULE_SIG_FORCE; if the kernel was not
97 configured with this option, then an invalid or unsigned module
98 simply taints the kernel.
99 ENOMEM Out of memory.
101 EPERM The caller was not privileged (did not have the CAP_SYS_MODULE
103 capability), or module loading is disabled (see /proc/sys/ker‐
104 nel/modules_disabled in proc(5)).
105 The following errors may additionally occur for init_module():
107 EEXIST A module with this name is already loaded.
109 EINVAL param_values is invalid, or some part of the ELF image in mod‐
111 ule_image contains inconsistencies.
112 ENOEXEC
114 The binary image supplied in module_image is not an ELF image,
115 or is an ELF image that is invalid or for a different architec‐
116 ture.
117 The following errors may additionally occur for finit_module():
119 EBADF The file referred to by fd is not opened for reading.
121 EFBIG The file referred to by fd is too large.
123 EINVAL flags is invalid.
125 ENOEXEC
127 fd does not refer to an open file.
128 In addition to the above errors, if the module's init function is exe‐
130 cuted and returns an error, then init_module() or finit_module() fails
131 and errno is set to the value returned by the init function.
132
134 finit_module () is available since Linux 3.8.
135
137 init_module() and finit_module() are Linux-specific.
138
140 Glibc does not provide a wrapper for these system calls; call them
141 using syscall(2).
142 Information about currently loaded modules can be found in /proc/mod‐
144 ules and in the file trees under the per-module subdirectories under
145 /sys/module.
146 See the Linux kernel source file include/linux/module.h for some useful
148 background information.
149 Linux 2.4 and earlier
151 In Linux 2.4 and earlier, the init_module() system call was rather dif‐
152 ferent:
153 #include <linux/module.h>
155 int init_module(const char *name, struct module *image);
157 (User-space applications can detect which version of init_module() is
159 available by calling query_module(); the latter call fails with the
160 error ENOSYS on Linux 2.6 and later.)
161 The older version of the system call loads the relocated module image
163 pointed to by image into kernel space and runs the module's init func‐
164 tion. The caller is responsible for providing the relocated image
165 (since Linux 2.6, the init_module() system call does the relocation).
166 The module image begins with a module structure and is followed by code
168 and data as appropriate. Since Linux 2.2, the module structure is
169 defined as follows:
170 struct module {
172 unsigned long size_of_struct;
173 struct module *next;
174 const char *name;
175 unsigned long size;
176 long usecount;
177 unsigned long flags;
178 unsigned int nsyms;
179 unsigned int ndeps;
180 struct module_symbol *syms;
181 struct module_ref *deps;
182 struct module_ref *refs;
183 int (*init)(void);
184 void (*cleanup)(void);
185 const struct exception_table_entry *ex_table_start;
186 const struct exception_table_entry *ex_table_end;
187 #ifdef __alpha__
188 unsigned long gp;
189 #endif
190 };
191 All of the pointer fields, with the exception of next and refs, are
193 expected to point within the module body and be initialized as appro‐
194 priate for kernel space, that is, relocated with the rest of the mod‐
195 ule.
196
198 create_module(2), delete_module(2), query_module(2), lsmod(8), mod‐
199 probe(8)
200
202 This page is part of release 3.53 of the Linux man-pages project. A
203 description of the project, and information about reporting bugs, can
204 be found at http://www.kernel.org/doc/man-pages/.
205Linux 2013-01-07 INIT_MODULE(2)