linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: mtk.manpages@gmail.com, Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-man <linux-man@vger.kernel.org>
Subject: Re: [PATCH] init_module: update to modern interfaces
Date: Thu, 11 Oct 2012 13:20:08 +1030	[thread overview]
Message-ID: <87wqyx7me7.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAKgNAkheF8=ssrE=_JP-ApDP5zXeHSYVG+0x6Wfd6U28TcPSHQ@mail.gmail.com>

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.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.

  reply	other threads:[~2012-10-11  3:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-20 23:27 [PATCH] init_module: update to modern interfaces Kees Cook
2012-10-09 21:30 ` Michael Kerrisk (man-pages)
2012-10-11  2:50   ` Rusty Russell [this message]
2012-10-12  7:42     ` Michael Kerrisk (man-pages)
2012-10-18  4:14       ` Rusty Russell
2012-10-18 12:54         ` Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wqyx7me7.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).