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.
WARNING: multiple messages have this Message-ID (diff)
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: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-06 1:34 [PATCH net-next] modules: allow modprobe load regular elf binaries Alexei Starovoitov 2018-03-06 1:34 ` Alexei Starovoitov 2018-03-06 2:13 ` Randy Dunlap 2018-03-06 3:02 ` Alexei Starovoitov 2018-03-06 3:02 ` Alexei Starovoitov 2018-03-06 11:05 ` Greg KH 2018-03-07 1:07 ` Alexei Starovoitov 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-08 23:07 ` Alexei Starovoitov 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 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 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-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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.