Synopsis

Note:
glibc provides no header file declaration of
init_module()
and no wrapper function for
finit_module();
see NOTES.

Description

init_module()
loads an ELF image into kernel space,
performs any necessary symbol relocations,
initializes module parameters to values provided by the caller,
and then runs the module's
init
function.
This system call requires privilege.

The
module_image
argument points to a buffer containing the binary image
to be loaded;
len
specifies the size of that buffer.
The module image should be a valid ELF image, built for the running kernel.

The
param_values
argument is a string containing space-delimited specifications of the
values for module parameters (defined inside the module using
module_param()
and
module_param_array()).
The kernel parses this string and initializes the specified
parameters.
Each of the parameter specifications has the form:

name[=value[,value...]]

The parameter
name
is one of those defined within the module using
module_param()
(see the Linux kernel source file
include/linux/moduleparam.h).
The parameter
value
is optional in the case of
bool
and
invbool
parameters.
Values for array parameters are specified as a comma-separated list.

finit_module()

The
finit_module()
system call is like
init_module(),
but reads the module to be loaded from the file descriptor
fd.
It is useful when the authenticity of a kernel module
can be determined from its location in the filesystem;
in cases where that is possible,
the overhead of using cryptographically signed modules to
determine the authenticity of a module can be avoided.
The
param_values
argument is as for
init_module().

The
flags
argument modifies the operation of
finit_module().
It is a bit mask value created by ORing
together zero or more of the following flags:

MODULE_INIT_IGNORE_MODVERSIONS

Ignore symbol version hashes.

MODULE_INIT_IGNORE_VERMAGIC

Ignore kernel version magic.

There are some safety checks built into a module to ensure that
it matches the kernel against which it is loaded.
These checks are recorded when the module is built and
verified when the module is loaded.
First, the module records a "vermagic" string containing
the kernel version number and prominent features (such as the CPU type).
Second, if the module was built with the
CONFIG_MODVERSIONS
configuration option enabled,
a version hash is recorded for each symbol the module uses.
This hash is based on the types of the arguments and return value
for the function named by the symbol.
In this case, the kernel version number within the
"vermagic" string is ignored,
as the symbol version hashes are assumed to be sufficiently reliable.

Using the
MODULE_INIT_IGNORE_VERMAGIC
flag indicates that the "vermagic" string is to be ignored, and the
MODULE_INIT_IGNORE_MODVERSIONS
flag indicates that the symbol version hashes are to be ignored.
If the kernel is built to permit forced loading (i.e., configured with
CONFIG_MODULE_FORCE_LOAD),
then loading will continue, otherwise it will fail with
ENOEXEC
as expected for malformed modules.

Return Value

On success, these system calls return 0.
On error, -1 is returned and
errno
is set appropriately.

Errors

EBADMSG (since Linux 3.7)

Module signature is misformatted.

EBUSY

Timeout while trying to resolve a symbol reference by this module.

EFAULT

An address argument referred to a location that
is outside the process's accessible address space.

ENOKEY (since Linux 3.7)

Module signature is invalid or
the kernel does not have a key for this module.
This error is returned only if the kernel was configured with
CONFIG_MODULE_SIG_FORCE;
if the kernel was not configured with this option,
then an invalid or unsigned module simply taints the kernel.

ENOMEM

Out of memory.

EPERM

The caller was not privileged
(did not have the
CAP_SYS_MODULE
capability),
or module loading is disabled
(see
/proc/sys/kernel/modules_disabled
in
proc(5)).

The following errors may additionally occur for
init_module():

EEXIST

A module with this name is already loaded.

EINVAL

param_values
is invalid, or some part of the ELF image in
module_image
contains inconsistencies.

ENOEXEC

The binary image supplied in
module_image
is not an ELF image,
or is an ELF image that is invalid or for a different architecture.

The following errors may additionally occur for
finit_module():

EBADF

The file referred to by
fd
is not opened for reading.

EFBIG

The file referred to by
fd
is too large.

EINVAL

flags
is invalid.

ENOEXEC

fd
does not refer to an open file.

In addition to the above errors, if the module's
init
function is executed and returns an error, then
init_module()
or
finit_module()
fails and
errno
is set to the value returned by the
init
function.

Versions

finit_module()
is available since Linux 3.8.

Conforming To

init_module()
and
finit_module()
are Linux-specific.

Notes

The
init_module()
system call is not supported by glibc.
No declaration is provided in glibc headers, but,
through a quirk of history, glibc does export an ABI for this system call.
Therefore, in order to employ this system call,
it is sufficient to manually declare the interface in your code;
alternatively, you can invoke the system call using
syscall(2).

Glibc does not provide a wrapper for
finit_module();
call it using
syscall(2).

Information about currently loaded modules can be found in
/proc/modules
and in the file trees under the per-module subdirectories under
/sys/module.

See the Linux kernel source file
include/linux/module.h
for some useful background information.

Linux 2.4 and earlier

In Linux 2.4 and earlier, the
init_module()
system call was rather different:

#include <linux/module.h>

int init_module(const char *name, struct module *image);

(User-space applications can detect which version of
init_module()
is available by calling
query_module();
the latter call fails with the error
ENOSYS
on Linux 2.6 and later.)

The older version of the system call
loads the relocated module image pointed to by
image
into kernel space and runs the module's
init
function.
The caller is responsible for providing the relocated image (since
Linux 2.6, the
init_module()
system call does the relocation).

The module image begins with a module structure and is followed by
code and data as appropriate.
Since Linux 2.2, the module structure is defined as follows:

All of the pointer fields, with the exception of
next
and
refs,
are expected to point within the module body and be
initialized as appropriate for kernel space, that is, relocated with
the rest of the module.

See Also

Colophon

This page is part of release 3.80 of the Linux
man-pages
project.
A description of the project,
information about reporting bugs,
and the latest version of this page,
can be found at
http://www.kernel.org/doc/man-pages/.

License & Copyright

Copyright (C) 2012 Michael Kerrisk
A few fragments remain from a version
Copyright (C) 1996 Free Software Foundation, Inc.
%%%LICENSE_START(VERBATIM)
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
Since the Linux kernel and libraries are constantly changing, this
manual page may be incorrect or out-of-date. The author(s) assume no
responsibility for errors or omissions, or for damages resulting from
the use of the information contained herein. The author(s) may not
have taken the same level of care in the production of this manual,
which is licensed free of charge, as they might when working
professionally.
Formatted or processed versions of this manual, if unaccompanied by
the source, must acknowledge the copyright and authors of this work.
%%%LICENSE_END