On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages) <mtk.manpages@xxxxxxxxx> wrote: > Hi Rusty, (and Lucas, and Kees) > > On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote: >> Michael Kerrisk <mtk.manpages@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
