From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
martin.lau@kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v2 bpf-next 02/10] bpf: reuse btf_prepare_func_args() check for main program BTF validation
Date: Wed, 13 Dec 2023 20:14:26 +0200 [thread overview]
Message-ID: <a23e5753192f152fbb09b98137fd0ecd8932efe5.camel@gmail.com> (raw)
In-Reply-To: <CAEf4Bza2v4=nwkV8BtLd7KvANtz1+j+GahFGYJCyKW93XPqF-A@mail.gmail.com>
On Wed, 2023-12-13 at 10:06 -0800, Andrii Nakryiko wrote:
[...]
> > > @@ -19944,21 +19945,19 @@ static int do_check_common(struct bpf_verifier_env *env, int subprog)
> > > }
> > > }
> > > } else {
> > > + /* if main BPF program has associated BTF info, validate that
> > > + * it's matching expected signature, and otherwise mark BTF
> > > + * info for main program as unreliable
> > > + */
> > > + if (env->prog->aux->func_info_aux) {
> > > + ret = btf_prepare_func_args(env, 0);
> > > + if (ret || sub->arg_cnt != 1 || sub->args[0].arg_type != ARG_PTR_TO_CTX)
> > > + env->prog->aux->func_info_aux[0].unreliable = true;
> > > + }
> >
> > Nit: should this return if ret == -EFAULT?
> >
> >
>
> no, why? I think the old behavior also didn't fail in this case
I think it did, here is an excerpt from the current patch:
- ret = btf_check_subprog_arg_match(env, subprog, regs);
- if (ret == -EFAULT)
- /* unlikely verifier bug. abort.
- * ret == 0 and ret < 0 are sadly acceptable for
- * main() function due to backward compatibility.
- * Like socket filter program may be written as:
- * int bpf_prog(struct pt_regs *ctx)
- * and never dereference that ctx in the program.
- * 'struct pt_regs' is a type mismatch for socket
- * filter that should be using 'struct __sk_buff'.
- */
- goto out;
next prev parent reply other threads:[~2023-12-13 18:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 23:25 [PATCH v2 bpf-next 00/10] Enhance BPF global subprogs with argument tags Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 01/10] bpf: abstract away global subprog arg preparation logic from reg state setup Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 02/10] bpf: reuse btf_prepare_func_args() check for main program BTF validation Andrii Nakryiko
2023-12-13 17:43 ` Eduard Zingerman
2023-12-13 18:06 ` Andrii Nakryiko
2023-12-13 18:14 ` Eduard Zingerman [this message]
2023-12-13 18:23 ` Andrii Nakryiko
2023-12-13 18:29 ` Eduard Zingerman
2023-12-12 23:25 ` [PATCH v2 bpf-next 03/10] bpf: prepare btf_prepare_func_args() for handling static subprogs Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 04/10] bpf: move subprog call logic back to verifier.c Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 05/10] bpf: reuse subprog argument parsing logic for subprog call checks Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 06/10] bpf: support 'arg:xxx' btf_decl_tag-based hints for global subprog args Andrii Nakryiko
2023-12-13 17:43 ` Eduard Zingerman
2023-12-13 19:18 ` Andrii Nakryiko
2023-12-13 19:33 ` Eduard Zingerman
2023-12-12 23:25 ` [PATCH v2 bpf-next 07/10] bpf: add support for passing dynptr pointer to global subprog Andrii Nakryiko
2023-12-13 17:43 ` Eduard Zingerman
2023-12-12 23:25 ` [PATCH v2 bpf-next 08/10] libbpf: add __arg_xxx macros for annotating global func args Andrii Nakryiko
2023-12-13 17:43 ` Eduard Zingerman
2023-12-12 23:25 ` [PATCH v2 bpf-next 09/10] selftests/bpf: add global subprog annotation tests Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 10/10] selftests/bpf: add freplace of BTF-unreliable main prog test Andrii Nakryiko
2023-12-13 17:44 ` Eduard Zingerman
2023-12-13 19:25 ` Andrii Nakryiko
2023-12-13 20:39 ` Eduard Zingerman
2023-12-13 22:48 ` Andrii Nakryiko
2023-12-14 0:14 ` Eduard Zingerman
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=a23e5753192f152fbb09b98137fd0ecd8932efe5.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@meta.com \
--cc=martin.lau@kernel.org \
/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.