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: glibc provides no header file declaration of init_module() and no
16 wrapper function for finit_module(); see NOTES.
17
19 init_module() loads an ELF image into kernel space, performs any neces‐
20 sary symbol relocations, initializes module parameters to values pro‐
21 vided by the caller, and then runs the module's init function. This
22 system call requires privilege.
23 The module_image argument points to a buffer containing the binary
25 image to be loaded; len specifies the size of that buffer. The module
26 image should be a valid ELF image, built for the running kernel.
27 The param_values argument is a string containing space-delimited speci‐
29 fications of the values for module parameters (defined inside the mod‐
30 ule using module_param() and module_param_array()). The kernel parses
31 this string and initializes the specified parameters. Each of the
32 parameter specifications has the form:
33 name[=value[,value...]]
35 The parameter name is one of those defined within the module using mod‐
37 ule_param() (see the Linux kernel source file include/linux/mod‐
38 uleparam.h). The parameter value is optional in the case of bool and
39 invbool parameters. Values for array parameters are specified as a
40 comma-separated list.
41 finit_module()
43 The finit_module() system call is like init_module(), but reads the
44 module to be loaded from the file descriptor fd. It is useful when the
45 authenticity of a kernel module can be determined from its location in
46 the filesystem; in cases where that is possible, the overhead of using
47 cryptographically signed modules to determine the authenticity of a
48 module can be avoided. The param_values argument is as for init_mod‐
49 ule().
50 The flags argument modifies the operation of finit_module(). It is a
52 bit mask value created by ORing together zero or more of the following
53 flags:
54 MODULE_INIT_IGNORE_MODVERSIONS
56 Ignore symbol version hashes.
57 MODULE_INIT_IGNORE_VERMAGIC
59 Ignore kernel version magic.
60 There are some safety checks built into a module to ensure that it
62 matches the kernel against which it is loaded. These checks are
63 recorded when the module is built and verified when the module is
64 loaded. First, the module records a "vermagic" string containing the
65 kernel version number and prominent features (such as the CPU type).
66 Second, if the module was built with the CONFIG_MODVERSIONS configura‐
67 tion option enabled, a version hash is recorded for each symbol the
68 module uses. This hash is based on the types of the arguments and
69 return value for the function named by the symbol. In this case, the
70 kernel version number within the "vermagic" string is ignored, as the
71 symbol version hashes are assumed to be sufficiently reliable.
72 Using the MODULE_INIT_IGNORE_VERMAGIC flag indicates that the "ver‐
74 magic" string is to be ignored, and the MODULE_INIT_IGNORE_MODVERSIONS
75 flag indicates that the symbol version hashes are to be ignored. If
76 the kernel is built to permit forced loading (i.e., configured with
77 CONFIG_MODULE_FORCE_LOAD), then loading continues, otherwise it fails
78 with the error ENOEXEC as expected for malformed modules.
79
81 On success, these system calls return 0. On error, -1 is returned and
82 errno is set appropriately.
83
85 EBADMSG (since Linux 3.7)
86 Module signature is misformatted.
87 EBUSY Timeout while trying to resolve a symbol reference by this mod‐
89 ule.
90 EFAULT An address argument referred to a location that is outside the
92 process's accessible address space.
93 ENOKEY (since Linux 3.7)
95 Module signature is invalid or the kernel does not have a key
96 for this module. This error is returned only if the kernel was
97 configured with CONFIG_MODULE_SIG_FORCE; if the kernel was not
98 configured with this option, then an invalid or unsigned module
99 simply taints the kernel.
100 ENOMEM Out of memory.
102 EPERM The caller was not privileged (did not have the CAP_SYS_MODULE
104 capability), or module loading is disabled (see /proc/sys/ker‐
105 nel/modules_disabled in proc(5)).
106 The following errors may additionally occur for init_module():
108 EEXIST A module with this name is already loaded.
110 EINVAL param_values is invalid, or some part of the ELF image in mod‐
112 ule_image contains inconsistencies.
113 ENOEXEC
115 The binary image supplied in module_image is not an ELF image,
116 or is an ELF image that is invalid or for a different architec‐
117 ture.
118 The following errors may additionally occur for finit_module():
120 EBADF The file referred to by fd is not opened for reading.
122 EFBIG The file referred to by fd is too large.
124 EINVAL flags is invalid.
126 ENOEXEC
128 fd does not refer to an open file.
129 In addition to the above errors, if the module's init function is exe‐
131 cuted and returns an error, then init_module() or finit_module() fails
132 and errno is set to the value returned by the init function.
133
135 finit_module() is available since Linux 3.8.
136
138 init_module() and finit_module() are Linux-specific.
139
141 The init_module() system call is not supported by glibc. No declara‐
142 tion is provided in glibc headers, but, through a quirk of history,
143 glibc versions before 2.23 did export an ABI for this system call.
144 Therefore, in order to employ this system call, it is (before glibc
145 2.23) sufficient to manually declare the interface in your code; alter‐
146 natively, you can invoke the system call using syscall(2).
147 Glibc does not provide a wrapper for finit_module(); call it using
149 syscall(2).
150 Information about currently loaded modules can be found in /proc/mod‐
152 ules and in the file trees under the per-module subdirectories under
153 /sys/module.
154 See the Linux kernel source file include/linux/module.h for some useful
156 background information.
157 Linux 2.4 and earlier
159 In Linux 2.4 and earlier, the init_module() system call was rather dif‐
160 ferent:
161 #include <linux/module.h>
163 int init_module(const char *name, struct module *image);
165 (User-space applications can detect which version of init_module() is
167 available by calling query_module(); the latter call fails with the
168 error ENOSYS on Linux 2.6 and later.)
169 The older version of the system call loads the relocated module image
171 pointed to by image into kernel space and runs the module's init func‐
172 tion. The caller is responsible for providing the relocated image
173 (since Linux 2.6, the init_module() system call does the relocation).
174 The module image begins with a module structure and is followed by code
176 and data as appropriate. Since Linux 2.2, the module structure is
177 defined as follows:
178 struct module {
180 unsigned long size_of_struct;
181 struct module *next;
182 const char *name;
183 unsigned long size;
184 long usecount;
185 unsigned long flags;
186 unsigned int nsyms;
187 unsigned int ndeps;
188 struct module_symbol *syms;
189 struct module_ref *deps;
190 struct module_ref *refs;
191 int (*init)(void);
192 void (*cleanup)(void);
193 const struct exception_table_entry *ex_table_start;
194 const struct exception_table_entry *ex_table_end;
195 #ifdef __alpha__
196 unsigned long gp;
197 #endif
198 };
199 All of the pointer fields, with the exception of next and refs, are
201 expected to point within the module body and be initialized as appro‐
202 priate for kernel space, that is, relocated with the rest of the mod‐
203 ule.
204
206 create_module(2), delete_module(2), query_module(2), lsmod(8), mod‐
207 probe(8)
208
210 This page is part of release 4.15 of the Linux man-pages project. A
211 description of the project, information about reporting bugs, and the
212 latest version of this page, can be found at
213 https://www.kernel.org/doc/man-pages/.
214Linux 2017-09-15 INIT_MODULE(2)