bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: YiFei Zhu <zhuyifei@google.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Jinghao Jia <jinghao7@illinois.edu>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>, Song Liu <song@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Jason Zhang <jdz@google.com>,
	Jann Horn <jannh@google.com>,
	mvle@us.ibm.com, zohar@linux.ibm.com, tyxu.uiuc@gmail.com,
	security@kernel.org
Subject: Re: [PATCH bpf 2/2] bpf: Add WARN_ON for recursive prog_run invocation
Date: Thu, 18 Aug 2022 00:30:25 +0200	[thread overview]
Message-ID: <cd514394-7712-ee0d-5c85-c6c7f62cec8e@iogearbox.net> (raw)
In-Reply-To: <20220816205517.682470-2-zhuyifei@google.com>

On 8/16/22 10:55 PM, YiFei Zhu wrote:
> Recursive invocation should not happen after commit 86f44fcec22c
> ("bpf: Disallow bpf programs call prog_run command."), unlike what
> is suggested in the comment. The only way to I can see this
> condition trigger is if userspace fetches an fd of a kernel-loaded
> lskel and attempt to race the kernel to execute that lskel... which
> also shouldn't happen under normal circumstances.
> 
> To make this "should never happen" explicit, clarify this in the
> comment and add a WARN_ON.
> 
> Fixes: 86f44fcec22c ("bpf: Disallow bpf programs call prog_run command.")
> Signed-off-by: YiFei Zhu <zhuyifei@google.com>
> ---
>   kernel/bpf/syscall.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 27760627370d..9cac9402c0bf 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -5119,8 +5119,8 @@ int kern_sys_bpf(int cmd, union bpf_attr *attr, unsigned int size)
>   
>   		run_ctx.bpf_cookie = 0;
>   		run_ctx.saved_run_ctx = NULL;
> -		if (!__bpf_prog_enter_sleepable(prog, &run_ctx)) {
> -			/* recursion detected */
> +		if (WARN_ON(!__bpf_prog_enter_sleepable(prog, &run_ctx))) {
> +			/* recursion detected, should never happen */

Pushed out commit 1/2, thanks! I think this one causes more confusion than value,
imho, for example in your commit log you state that it could trigger when attempting
to race, in the comment you state "should never happen". Which one is it? Also, if
we can recover gracefully in this case, what should the user do with the warn (I
guess worst case warn_on_once), but still?

Thanks,
Daniel

  reply	other threads:[~2022-08-17 22:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16 20:55 [PATCH bpf 1/2] bpf: Restrict bpf_sys_bpf to CAP_PERFMON YiFei Zhu
2022-08-16 20:55 ` [PATCH bpf 2/2] bpf: Add WARN_ON for recursive prog_run invocation YiFei Zhu
2022-08-17 22:30   ` Daniel Borkmann [this message]
2022-08-17 23:20     ` YiFei Zhu
2022-08-17 22:30 ` [PATCH bpf 1/2] bpf: Restrict bpf_sys_bpf to CAP_PERFMON patchwork-bot+netdevbpf

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=cd514394-7712-ee0d-5c85-c6c7f62cec8e@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jannh@google.com \
    --cc=jdz@google.com \
    --cc=jinghao7@illinois.edu \
    --cc=mvle@us.ibm.com \
    --cc=sdf@google.com \
    --cc=security@kernel.org \
    --cc=song@kernel.org \
    --cc=tyxu.uiuc@gmail.com \
    --cc=zhuyifei@google.com \
    --cc=zohar@linux.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;
as well as URLs for NNTP newsgroup(s).