From: Lucas De Marchi <lucas.demarchi@profusion.mobi>
To: mtk.manpages@gmail.com
Cc: Rusty Russell <rusty@rustcorp.com.au>,
"H. Peter Anvin" <hpa@zytor.com>,
Kees Cook <keescook@chromium.org>,
linux-kernel@vger.kernel.org, jonathon@jonmasters.org,
linux-man@vger.kernel.org
Subject: Re: [PATCH 1/4] module: add syscall to load module from fd
Date: Wed, 9 Jan 2013 15:29:37 -0200 [thread overview]
Message-ID: <CAMOw1v6Jk7adSeppunBe0GaW3w3MREU0_hW68_Fbh2599jctkg@mail.gmail.com> (raw)
In-Reply-To: <CAKgNAkggu9+AuMRqTFeNy9sJVCMcZVRZx43t=svF=gm+P4DnuQ@mail.gmail.com>
On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> Hi Rusty, (and Lucas, and Kees)
>
> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> 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?
>
> 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
next prev parent reply other threads:[~2013-01-09 17:30 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-20 22:14 [PATCH 1/4] module: add syscall to load module from fd Kees Cook
2012-09-20 22:14 ` [PATCH 2/4] security: introduce kernel_module_from_file hook Kees Cook
2012-09-21 12:42 ` Mimi Zohar
2012-09-20 22:14 ` [PATCH 3/4] ARM: add finit_module syscall to ARM Kees Cook
2012-09-21 13:15 ` Arnd Bergmann
2012-09-21 14:59 ` Russell King
2012-09-21 15:43 ` Kees Cook
2012-09-20 22:15 ` [PATCH 4/4] add finit_module syscall to asm-generic Kees Cook
2012-09-21 2:22 ` [PATCH 1/4] module: add syscall to load module from fd James Morris
2012-09-21 3:07 ` Kees Cook
2012-09-21 3:09 ` Mimi Zohar
2012-09-21 17:56 ` John Johansen
2012-10-03 22:40 ` Kees Cook
2012-10-04 5:39 ` Rusty Russell
2012-10-04 12:50 ` Mimi Zohar
2012-10-05 3:50 ` Rusty Russell
2012-10-05 7:12 ` Kees Cook
2012-10-04 20:28 ` Kees Cook
2012-10-09 21:54 ` Michael Kerrisk
2012-10-09 21:58 ` H. Peter Anvin
2012-10-09 22:03 ` Michael Kerrisk (man-pages)
2012-10-09 22:09 ` H. Peter Anvin
[not found] ` <CAKgNAkjfkbYOQocuGRAKU=0P2CQCvmedhRMJZPnkUMnnxSOsqg@mail.gmail.com>
2012-10-10 5:54 ` Michael Kerrisk (man-pages)
2012-10-11 22:16 ` Rusty Russell
2012-10-12 5:16 ` Michael Kerrisk (man-pages)
2012-10-18 3:12 ` Rusty Russell
2012-10-18 5:39 ` Lucas De Marchi
2012-10-18 12:59 ` Michael Kerrisk (man-pages)
2012-10-22 7:39 ` Rusty Russell
2012-10-23 2:37 ` Lucas De Marchi
2012-10-23 3:40 ` Kees Cook
2012-10-23 4:08 ` Lucas De Marchi
2012-10-23 15:42 ` Kees Cook
2012-10-23 15:45 ` H. Peter Anvin
2012-10-23 16:25 ` Lucas De Marchi
2012-10-24 3:06 ` Rusty Russell
2012-10-23 7:38 ` Michael Kerrisk (man-pages)
2012-10-30 21:57 ` Kees Cook
2012-11-01 1:03 ` Rusty Russell
2012-12-21 0:01 ` Michael Kerrisk
2013-01-03 0:12 ` Rusty Russell
2013-01-06 18:59 ` Michael Kerrisk (man-pages)
2013-01-06 20:24 ` Kees Cook
2013-01-07 1:41 ` Michael Kerrisk (man-pages)
2013-01-09 17:29 ` Lucas De Marchi [this message]
2013-01-10 0:55 ` Michael Kerrisk (man-pages)
2012-10-18 4:24 ` H. Peter Anvin
2012-10-18 8:05 ` Michael Kerrisk (man-pages)
2012-10-18 14:26 ` H. Peter Anvin
2012-10-18 15:28 ` Kees Cook
2012-10-18 15:30 ` H. Peter Anvin
2012-10-19 2:23 ` Rusty Russell
2012-10-19 2:54 ` H. Peter Anvin
2012-10-19 10:46 ` Alon Ziv
2012-10-20 4:05 ` Rusty Russell
-- strict thread matches above, loose matches on Subject: below --
2012-10-04 20:22 [PATCH v5] " Kees Cook
2012-10-04 20:22 ` [PATCH 1/4] " Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMOw1v6Jk7adSeppunBe0GaW3w3MREU0_hW68_Fbh2599jctkg@mail.gmail.com \
--to=lucas.demarchi@profusion.mobi \
--cc=hpa@zytor.com \
--cc=jonathon@jonmasters.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).