lkml.org 
[lkml]   [2013]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 1/4] module: add syscall to load module from fd
    On Wed, Jan 9, 2013 at 6:29 PM, Lucas De Marchi
    <lucas.demarchi@profusion.mobi> wrote:
    > On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
    > <mtk.manpages@gmail.com> wrote:
    >> Hi Rusty, (and Lucas, and Kees)
    >>
    >> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
    >>> Michael Kerrisk <mtk.manpages@gmail.com> writes:
    >>>> Hi Rusty,
    >>>
    >>> Hi Michael,
    >>>
    >>>> The description here is rather thin. Could you supply a sentence or
    >>>> two for each of MODULE_INIT_IGNORE_MODVERSIONS and
    >>>> MODULE_INIT_IGNORE_VERMAGIC that would be suitable for the manual
    >>>> page?
    >>>>
    >>>> Thanks,
    >>>
    >>> There are one or two safety checks built into a module, which are
    >>> checked to match the kernel on module load. The first is a "vermagic"
    >>> string containing the kernel version number and prominent features (such
    >>> as CPU type). If the module was built with CONFIG_MODVERSIONS set, a
    >>> version hash is recorded for each symbol the module uses based on the
    >>> types it refers to: 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
    >>> is to be ignored, and the MODULE_INIT_IGNORE_MODVERSIONS flag indicates
    >>> that the version hashes are to be ignored. If the kernel is built to
    >>> permit such forced loading (ie. CONFIG_MODULE_FORCE_LOAD is set) then
    >>> loading will continue, otherwise it will fail with ENOEXEC as expected
    >>> for malformed modules.
    >>>
    >>> Hope that is more usable?
    >>
    >> Yes, that helps. I did some reworking of that text. Hopefully, I did
    >> not introduce any errors.
    >>
    >> Below is the text that is proposed to document finit_module() in the
    >> man pages. I'd appreciate any review (Kees, Lucas, Rusty?)
    >>
    >> Thanks,
    >>
    >> Michael
    >>
    >> 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 deter‐
    >> mined from its location in the file system; 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 fea‐
    >> tures (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 MOD‐
    >> ULE_INIT_IGNORE_MODVERSIONS flag indicates that the symbol ver‐
    >> sion hashes are to be ignored. If the kernel is built to per‐
    >> mit forced loading (i.e., configured with CONFIG_MOD‐
    >> ULE_FORCE_LOAD), then loading will continue, otherwise it will
    >> fail with ENOEXEC as expected for malformed modules.
    >> ...
    >> ERRORS
    >> ...
    >> 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.
    >>
    >>
    >
    >
    > Looks good to me.

    Thanks for looking it over, Lucas.

    Cheers,

    Michael

    --
    Michael Kerrisk
    Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
    Author of "The Linux Programming Interface"; http://man7.org/tlpi/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2013-01-10 02:21    [W:4.244 / U:1.208 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site