Re: [PATCH 1/4] module: add syscall to load module from fd

Re: [PATCH 1/4] module: add syscall to load module from fd

[Michael Kerrisk]

Hi Rusty,

On Mon, Oct 22, 2012 at 9:39 AM, Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>>
>> Acked-by: Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Here's the version I ended up with when I added two flags.
>
> Lucas, is this useful to you?
>
> BTW Michael: why aren't the syscall man pages in the kernel source?
>
> Thanks,
> Rusty.
>
> module: add flags arg to sys_finit_module()
>
> Thanks to Michael Kerrisk for keeping us honest.  These flags are actually
> useful for eliminating the only case where kmod has to mangle a module's
> internals: for overriding module versioning.

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,

Michael


>
> Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
>
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 32bc035..8cf7b50 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -868,5 +868,5 @@ asmlinkage long sys_process_vm_writev(pid_t pid,
>
>  asmlinkage long sys_kcmp(pid_t pid1, pid_t pid2, int type,
>                          unsigned long idx1, unsigned long idx2);
> -asmlinkage long sys_finit_module(int fd, const char __user *uargs);
> +asmlinkage long sys_finit_module(int fd, const char __user *uargs, int flags);
>  #endif
> diff --git a/include/uapi/linux/module.h b/include/uapi/linux/module.h
> new file mode 100644
> index 0000000..38da425
> --- /dev/null
> +++ b/include/uapi/linux/module.h
> @@ -0,0 +1,8 @@
> +#ifndef _UAPI_LINUX_MODULE_H
> +#define _UAPI_LINUX_MODULE_H
> +
> +/* Flags for sys_finit_module: */
> +#define MODULE_INIT_IGNORE_MODVERSIONS 1
> +#define MODULE_INIT_IGNORE_VERMAGIC    2
> +
> +#endif /* _UAPI_LINUX_MODULE_H */
> diff --git a/kernel/module.c b/kernel/module.c
> index 261bf82..55b49cd 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -61,6 +61,7 @@
>  #include <linux/pfn.h>
>  #include <linux/bsearch.h>
>  #include <linux/fips.h>
> +#include <uapi/linux/module.h>
>  #include "module-internal.h"
>
>  #define CREATE_TRACE_POINTS
> @@ -2569,7 +2570,7 @@ static void free_copy(struct load_info *info)
>         vfree(info->hdr);
>  }
>
> -static int rewrite_section_headers(struct load_info *info)
> +static int rewrite_section_headers(struct load_info *info, int flags)
>  {
>         unsigned int i;
>
> @@ -2597,7 +2598,10 @@ static int rewrite_section_headers(struct load_info *info)
>         }
>
>         /* Track but don't keep modinfo and version sections. */
> -       info->index.vers = find_sec(info, "__versions");
> +       if (flags & MODULE_INIT_IGNORE_MODVERSIONS)
> +               info->index.vers = 0; /* Pretend no __versions section! */
> +       else
> +               info->index.vers = find_sec(info, "__versions");
>         info->index.info = find_sec(info, ".modinfo");
>         info->sechdrs[info->index.info].sh_flags &= ~(unsigned long)SHF_ALLOC;
>         info->sechdrs[info->index.vers].sh_flags &= ~(unsigned long)SHF_ALLOC;
> @@ -2612,7 +2617,7 @@ static int rewrite_section_headers(struct load_info *info)
>   * Return the temporary module pointer (we'll replace it with the final
>   * one when we move the module sections around).
>   */
> -static struct module *setup_load_info(struct load_info *info)
> +static struct module *setup_load_info(struct load_info *info, int flags)
>  {
>         unsigned int i;
>         int err;
> @@ -2623,7 +2628,7 @@ static struct module *setup_load_info(struct load_info *info)
>         info->secstrings = (void *)info->hdr
>                 + info->sechdrs[info->hdr->e_shstrndx].sh_offset;
>
> -       err = rewrite_section_headers(info);
> +       err = rewrite_section_headers(info, flags);
>         if (err)
>                 return ERR_PTR(err);
>
> @@ -2661,11 +2666,14 @@ static struct module *setup_load_info(struct load_info *info)
>         return mod;
>  }
>
> -static int check_modinfo(struct module *mod, struct load_info *info)
> +static int check_modinfo(struct module *mod, struct load_info *info, int flags)
>  {
>         const char *modmagic = get_modinfo(info, "vermagic");
>         int err;
>
> +       if (flags & MODULE_INIT_IGNORE_VERMAGIC)
> +               modmagic = NULL;
> +
>         /* This is allowed: modprobe --force will invalidate it. */
>         if (!modmagic) {
>                 err = try_to_force_load(mod, "bad vermagic");
> @@ -2901,18 +2909,18 @@ int __weak module_frob_arch_sections(Elf_Ehdr *hdr,
>         return 0;
>  }
>
> -static struct module *layout_and_allocate(struct load_info *info)
> +static struct module *layout_and_allocate(struct load_info *info, int flags)
>  {
>         /* Module within temporary copy. */
>         struct module *mod;
>         Elf_Shdr *pcpusec;
>         int err;
>
> -       mod = setup_load_info(info);
> +       mod = setup_load_info(info, flags);
>         if (IS_ERR(mod))
>                 return mod;
>
> -       err = check_modinfo(mod, info);
> +       err = check_modinfo(mod, info, flags);
>         if (err)
>                 return ERR_PTR(err);
>
> @@ -3094,7 +3102,8 @@ static int may_init_module(void)
>
>  /* Allocate and load the module: note that size of section 0 is always
>     zero, and we rely on this for optional sections. */
> -static int load_module(struct load_info *info, const char __user *uargs)
> +static int load_module(struct load_info *info, const char __user *uargs,
> +                      int flags)
>  {
>         struct module *mod, *old;
>         long err;
> @@ -3108,7 +3117,7 @@ static int load_module(struct load_info *info, const char __user *uargs)
>                 goto free_copy;
>
>         /* Figure out module layout, and allocate all the memory. */
> -       mod = layout_and_allocate(info);
> +       mod = layout_and_allocate(info, flags);
>         if (IS_ERR(mod)) {
>                 err = PTR_ERR(mod);
>                 goto free_copy;
> @@ -3257,10 +3269,10 @@ SYSCALL_DEFINE3(init_module, void __user *, umod,
>         if (err)
>                 return err;
>
> -       return load_module(&info, uargs);
> +       return load_module(&info, uargs, 0);
>  }
>
> -SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
> +SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
>  {
>         int err;
>         struct load_info info = { };
> @@ -3269,13 +3281,17 @@ SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
>         if (err)
>                 return err;
>
> -       pr_debug("finit_module: fd=%d, uargs=%p\n", fd, uargs);
> +       pr_debug("finit_module: fd=%d, uargs=%p, flags=%i\n", fd, uargs, flags);
> +
> +       if (flags & ~(MODULE_INIT_IGNORE_MODVERSIONS
> +                     |MODULE_INIT_IGNORE_VERMAGIC))
> +               return -EINVAL;
>
>         err = copy_module_from_fd(fd, &info);
>         if (err)
>                 return err;
>
> -       return load_module(&info, uargs);
> +       return load_module(&info, uargs, flags);
>  }
>
>  static inline int within(unsigned long addr, void *start, unsigned long size)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



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

Re: [PATCH 1/4] module: add syscall to load module from fd

[Rusty Russell]

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?

Thanks,
Rusty,

Re: [PATCH 1/4] module: add syscall to load module from fd

[Michael Kerrisk (man-pages)]

Hi Rusty, (and Lucas, and Kees)

On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote:
> Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.


-- 
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-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] module: add syscall to load module from fd

[Kees Cook]

On Sun, Jan 6, 2013 at 11:59 AM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Rusty, (and Lucas, and Kees)
>
> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote:
>> Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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?)

Looks good to me!

Reviewed-by: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

-Kees

--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] module: add syscall to load module from fd

[Michael Kerrisk (man-pages)]

On Sun, Jan 6, 2013 at 9:24 PM, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> On Sun, Jan 6, 2013 at 11:59 AM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Rusty, (and Lucas, and Kees)
>>
>> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote:
>>> Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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?)
>
> Looks good to me!
>
> Reviewed-by: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Thanks Kees!



-- 
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-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] module: add syscall to load module from fd

[Lucas De Marchi]

On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Rusty, (and Lucas, and Kees)
>
> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote:
>> Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.


regards,
Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] module: add syscall to load module from fd

[Michael Kerrisk (man-pages)]

On Wed, Jan 9, 2013 at 6:29 PM, Lucas De Marchi
<lucas.demarchi-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org> wrote:
> On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Rusty, (and Lucas, and Kees)
>>
>> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org> wrote:
>>> Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html