All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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: link
Be 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.