| 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
| ||
|
Date: Thu, 10 Jan 2013 01:55:53 +0100 From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> To: Lucas De Marchi <lucas.demarchi@...fusion.mobi> Cc: Rusty Russell <rusty@...tcorp.com.au>, "H. Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org, jonathon@...masters.org, linux-man@...r.kernel.org Subject: Re: [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@...fusion.mobi> wrote: > On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages) > <mtk.manpages@...il.com> wrote: >> Hi Rusty, (and Lucas, and Kees) >> >> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell <rusty@...tcorp.com.au> wrote: >>> Michael Kerrisk <mtk.manpages@...il.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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists