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

From: Michael Kerrisk (man-pages)
Date: Sun Jan 06 2013 - 14:00:11 EST


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.


--
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/