On Sun, Jan 6, 2013 at 11:59 AM, 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?) Looks good to me! Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> -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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
