From: Alexei Starovoitov <ast@fb.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>,
Alexei Starovoitov <ast@kernel.org>
Cc: <davem@davemloft.net>, <daniel@iogearbox.net>,
<torvalds@linux-foundation.org>, <gregkh@linuxfoundation.org>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<kernel-team@fb.com>, <linux-api@vger.kernel.org>,
Jessica Yu <jeyu@kernel.org>, Kees Cook <keescook@chromium.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Jiri Kosina <jikos@kernel.org>
Subject: Re: [PATCH net-next] modules: allow modprobe load regular elf binaries
Date: Thu, 8 Mar 2018 15:07:01 -0800 [thread overview]
Message-ID: <d83869b4-260e-179d-d469-83b8d8068399@fb.com> (raw)
In-Reply-To: <20180308012353.GO14069@wotan.suse.de>
On 3/7/18 5:23 PM, Luis R. Rodriguez wrote:
>
> request_module() has its own world though too. How often in your proof of
> concept is request_module() called? How many times do you envision it being
> called?
once.
>> +static int run_umh(struct file *file)
>> +{
>> + struct subprocess_info *sub_info = call_usermodehelper_setup_file(file);
>> +
>> + if (!sub_info)
>> + return -ENOMEM;
>> + return call_usermodehelper_exec(sub_info, UMH_WAIT_EXEC);
>> +}
>
> run_umh() calls the program and waits. Note that while we are running a UMH we
> can't suspend. What if they take forever, who is hosing them down with an
> equivalent:
>
> schedule();
> try_to_freeze();
>
> Say they are buggy and never return, will they stall suspend, have you tried?
>
> call_usermodehelper_exec() uses helper_lock() which in turn is used for
> umh's accounting for number of running umh's. One of the sad obscure uses
> for this is to deal with suspend/resume. Refer to __usermodehelper* calls
> on kernel/power/process.c
>
> Note how you use UMH_WAIT_EXEC too, so this is all synchronous.
looks like you misread this code and the rest of your concerns
with suspend/resume are not applicable any more.
#define UMH_NO_WAIT 0 /* don't wait at all */
#define UMH_WAIT_EXEC 1 /* wait for the exec, but not the process */
#define UMH_WAIT_PROC 2 /* wait for the process to complete */
#define UMH_KILLABLE 4 /* wait for EXEC/PROC killable */
bpftiler.ko is started once and runs non-stop from there on.
Unless it crashes, but it's a different discussion.
>> + if (info->hdr->e_type == ET_EXEC) {
>> +#ifdef CONFIG_MODULE_SIG
>> + if (!info->sig_ok) {
>> + pr_notice_once("umh %s verification failed: signature and/or required key missing - tainting kernel\n",
>> + info->file->f_path.dentry->d_name.name);
>> + add_taint(TAINT_UNSIGNED_MODULE, LOCKDEP_STILL_OK);
>> + }
>> +#endif
>
> So I guess this check is done *after* run_umh() then, what about the enforce mode,
> don't we want to reject loading at all in any circumstance?
already answered this twice in the thread.
next prev parent reply other threads:[~2018-03-08 23:07 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-06 1:34 Alexei Starovoitov
2018-03-06 2:13 ` Randy Dunlap
2018-03-06 3:02 ` Alexei Starovoitov
2018-03-06 11:05 ` Greg KH
2018-03-07 1:07 ` Alexei Starovoitov
2018-03-07 3:24 ` Greg KH
2018-03-06 19:12 ` Linus Torvalds
2018-03-06 23:42 ` Chris Mason
2018-05-02 9:12 ` Jesper Dangaard Brouer
2018-03-06 20:01 ` Andy Lutomirski
2018-03-06 20:26 ` Linus Torvalds
2018-03-07 17:22 ` David Miller
2018-03-08 1:23 ` Luis R. Rodriguez
2018-03-08 23:07 ` Alexei Starovoitov [this message]
2018-03-09 1:58 ` Luis R. Rodriguez
2018-03-09 0:24 ` Kees Cook
2018-03-09 0:57 ` Alexei Starovoitov
2018-03-09 1:04 ` Andy Lutomirski
2018-03-09 1:25 ` Alexei Starovoitov
2018-03-09 1:24 ` Kees Cook
2018-03-09 0:59 ` Andy Lutomirski
2018-03-09 1:20 ` Alexei Starovoitov
2018-03-09 2:12 ` Andy Lutomirski
2018-03-09 2:31 ` David Miller
2018-03-09 3:10 ` Andy Lutomirski
2018-03-09 3:27 ` Alexei Starovoitov
2018-03-09 1:38 ` Linus Torvalds
2018-03-09 1:44 ` Kees Cook
2018-03-09 3:06 ` Linus Torvalds
2018-03-09 3:17 ` Linus Torvalds
2018-03-09 3:54 ` Andy Lutomirski
2018-03-09 5:08 ` Alexei Starovoitov
2018-03-09 15:16 ` Andy Lutomirski
2018-03-09 15:39 ` Alexei Starovoitov
2018-03-09 16:24 ` Andy Lutomirski
2018-03-09 17:32 ` Alexei Starovoitov
2018-03-09 18:15 ` Greg KH
2018-03-09 18:23 ` Andy Lutomirski
2018-03-09 18:29 ` Greg KH
2018-03-09 18:50 ` Alexei Starovoitov
2018-03-09 18:55 ` David Miller
2018-03-09 19:37 ` Andy Lutomirski
2018-03-10 1:43 ` Alexei Starovoitov
2018-03-11 2:17 ` Andy Lutomirski
2018-03-09 18:17 ` Linus Torvalds
2018-03-09 18:35 ` David Miller
2018-03-09 18:43 ` Kees Cook
2018-03-09 18:50 ` Linus Torvalds
2018-03-09 18:54 ` Kees Cook
2018-03-09 18:58 ` Alexei Starovoitov
2018-03-12 12:02 ` Edward Cree
2018-03-12 17:49 ` Alexei Starovoitov
2018-03-09 18:48 ` Andy Lutomirski
2018-03-09 18:53 ` Linus Torvalds
2018-03-09 18:57 ` David Miller
2018-03-09 19:12 ` Linus Torvalds
2018-03-09 19:38 ` Linus Torvalds
2018-03-09 19:45 ` Andy Lutomirski
2018-03-10 2:34 ` Alexei Starovoitov
2018-03-10 14:08 ` Luis R. Rodriguez
2018-03-10 15:16 ` Luis R. Rodriguez
2018-03-10 15:34 ` Luis R. Rodriguez
2018-03-12 17:22 ` Alexei Starovoitov
2018-03-13 8:48 ` Greg Kroah-Hartman
2018-03-22 20:54 ` Luis R. Rodriguez
2018-03-22 22:15 ` Andy Lutomirski
2018-03-22 22:21 ` Alexei Starovoitov
2018-03-23 2:47 ` Luis R. Rodriguez
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=d83869b4-260e-179d-d469-83b8d8068399@fb.com \
--to=ast@fb.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=jeyu@kernel.org \
--cc=jikos@kernel.org \
--cc=keescook@chromium.org \
--cc=kernel-team@fb.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=torvalds@linux-foundation.org \
--cc=zohar@linux.vnet.ibm.com \
/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
all inboxes | Powered by JetHome®