linux-kernel - Re: [PATCH] init_module: update to modern interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87wqyx7me7.fsf@rustcorp.com.au>
Date:	Thu, 11 Oct 2012 13:20:08 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	mtk.manpages@...il.com, Kees Cook <keescook@...omium.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-man <linux-man@...r.kernel.org>
Subject: Re: [PATCH] init_module: update to modern interfaces

"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:
> [CC widened, so that some more review might come in. Rusty?]

Sure.

Looks good. but:

> .B EBUSY
> The module's initialization routine failed.

Possibly.  You should mention that the individual module's
initialization routine can return other errors as appropriate.

> .BR EINVAL " (Linux 2.4 and earlier)"
> Some
> .I image
> slot is filled in incorrectly,
> .I image\->name
> does not correspond to the original module name, some
> .I image\->deps
> entry does not correspond to a loaded module,
> or some other similar inconsistency.
> .TP

Why document this?

> .B ENOEXEC
> The ELF image in
> .I module_image
> is too small or has corrupted segments.

Or is not an ELF image, or wrong arch...

> .TP
> .B EPERM
> The caller was not privileged
> (did not have the
> .B CAP_SYS_MODULE
> capability),
> or module loading is disabled
> (see
> .IR /proc/sys/kernel/modules_disabled
> in
> .BR proc (5)).
> .SH "CONFORMING TO"
> .BR init_module ()
> is Linux-specific.
> .SH NOTES
> Glibc does not provide a wrapper for this system call; call it using
> .BR syscall (2).
>
> Information about currently loaded modules can be found in
> .IR /proc/modules
> and in the file trees under the per-module subdirectories under
> .IR /sys/module .
>
> See the Linux kernel source file
> .I include/linux/module.h
> for some useful background information.
> .SS Linux 2.4 and earlier
> .PP
> In Linux 2.4 and earlier, this system call was rather different:
>
> .B "    #include <linux/module.h>"
>
> .BI "    int init_module(const char *" name ", struct module *" image );
>
> This version of the system call
> loads the relocated module image pointed to by
> .I image
> into kernel space and runs the module's
> .I init
> function.
> The caller is responsible for providing the relocated image (since
> Linux 2.6, the
> .BR init_module ()
> system call does the relocation).
> .PP
> The module image begins with a module structure and is followed by
> code and data as appropriate.
> The module structure is defined as follows:
> .PP
> .in +4n
> .nf
> 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
> };
> .fi
> .in
> .PP
> All of the pointer fields, with the exception of
> .I next
> and
> .IR 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.

You might want to note that the 2.4 syscall can be detected by calling
query_module(): 2.6 and above give ENOSYS.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/