Provided by: manpages-dev_6.8-2_all bug

NAME

       init_module, finit_module - load a kernel module

LIBRARY

       Standard C library (libc, -lc)

SYNOPSIS

       #include <linux/module.h>    /* Definition of MODULE_* constants */
       #include <sys/syscall.h>     /* Definition of SYS_* constants */
       #include <unistd.h>

       int syscall(SYS_init_module, void module_image[.len], unsigned long len,
                   const char *param_values);
       int syscall(SYS_finit_module, int fd,
                   const char *param_values, int flags);

       Note:  glibc  provides  no  wrappers  for  these  system  calls,  necessitating the use of
       syscall(2).

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.

       MODULE_INIT_COMPRESSED_FILE (since Linux 5.17)
              Use in-kernel module decompression.

       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 continues, otherwise it fails with
       the error ENOEXEC as expected for malformed modules.

       If the kernel was build with CONFIG_MODULE_DECOMPRESS, the in-kernel decompression feature
       can be used.  User-space code can check if the kernel supports  decompression  by  reading
       the   /sys/module/compression  attribute.   If  the  kernel  supports  decompression,  the
       compressed   file   can   directly    be    passed    to    finit_module()    using    the
       MODULE_INIT_COMPRESSED_FILE   flag.    The  in-kernel  module  decompressor  supports  the
       following compression algorithms:

           •  gzip (since Linux 5.17)
           •  xz (since Linux 5.17)
           •  zstd (since Linux 6.2)

       The kernel only implements a single decompression method.  This is selected during  module
       generation accordingly to the compression method chosen in the kernel configuration.

RETURN VALUE

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

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.

       EINVAL The  decompressor sanity checks failed, while loading a compressed module with flag
              MODULE_INIT_COMPRESSED_FILE set.

       ENOEXEC
              fd does not refer to an open file.

       EOPNOTSUPP (since Linux 5.17)
              The flag MODULE_INIT_COMPRESSED_FILE is set to load a compressed  module,  and  the
              kernel was built without CONFIG_MODULE_DECOMPRESS.

       ETXTBSY (since Linux 4.7)
              The file referred to by fd is opened for read-write.

       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.

STANDARDS

       Linux.

HISTORY

       finit_module()
              Linux 3.8.

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

   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:

           struct module {
               unsigned long         size_of_struct;
               struct module        *next;
               const char           *name;
               unsigned long         size;
               long                  usecount;
               unsigned long         flags;
               unsigned int          nsyms;
               unsigned int          ndeps;
               struct module_symbol *syms;
               struct module_ref    *deps;
               struct module_ref    *refs;
               int                 (*init)(void);
               void                (*cleanup)(void);
               const struct exception_table_entry *ex_table_start;
               const struct exception_table_entry *ex_table_end;
           #ifdef __alpha__
               unsigned long gp;
           #endif
           };

       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.

NOTES

       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.

SEE ALSO

       create_module(2), delete_module(2), query_module(2), lsmod(8), modprobe(8)