From: Martin KaFai Lau <martin.lau@linux.dev>
To: Lorenz Bauer <lmb@isovalent.com>
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>, Song Liu <song@kernel.org>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>
Subject: Re: [PATCH bpf-next] bpf: btf: restore resolve_mode when popping the resolve stack
Date: Tue, 16 May 2023 23:26:50 -0700 [thread overview]
Message-ID: <a29c604e-5a68-eed2-b581-0ad4687fda10@linux.dev> (raw)
In-Reply-To: <20230515121521.30569-1-lmb@isovalent.com>
On 5/15/23 5:15 AM, Lorenz Bauer wrote:
> In commit 9b459804ff99 ("btf: fix resolving BTF_KIND_VAR after ARRAY, STRUCT, UNION, PTR")
> I fixed a bug that occurred during resolving of a DATASEC by strategically resetting
> resolve_mode. This fixes the immediate bug but leaves us open to future bugs where
> nested types have to be resolved.
hmm... future bugs like when adding new BTF_KIND in the future?
>
> The problem is that env_stack_pop_resolved never restores the previously active
> resolve mode when discarding a stack item. Fix this by adding the previous resolve
> mode to each resolve_vertex and updating env->resolve_mode during pop.
>
> Signed-off-by: Lorenz Bauer <lmb@isovalent.com>
> ---
> kernel/bpf/btf.c | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 6b682b8e4b50..4d6c1d0e8b7c 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -264,10 +264,19 @@ enum verifier_phase {
> CHECK_TYPE,
> };
>
> +enum resolve_mode {
> + RESOLVE_TBD, /* To Be Determined */
> + RESOLVE_PTR, /* Resolving for Pointer */
> + RESOLVE_STRUCT_OR_ARRAY, /* Resolving for struct/union
> + * or array
> + */
> +};
> +
> struct resolve_vertex {
> const struct btf_type *t;
> u32 type_id;
> u16 next_member;
> + enum resolve_mode parent_mode;
> };
>
> enum visit_state {
> @@ -276,13 +285,6 @@ enum visit_state {
> RESOLVED,
> };
>
> -enum resolve_mode {
> - RESOLVE_TBD, /* To Be Determined */
> - RESOLVE_PTR, /* Resolving for Pointer */
> - RESOLVE_STRUCT_OR_ARRAY, /* Resolving for struct/union
> - * or array
> - */
> -};
>
> #define MAX_RESOLVE_DEPTH 32
>
> @@ -1811,6 +1813,7 @@ static int env_stack_push(struct btf_verifier_env *env,
> v->t = t;
> v->type_id = type_id;
> v->next_member = 0;
> + v->parent_mode = env->resolve_mode;
>
> if (env->resolve_mode == RESOLVE_TBD) {
> if (btf_type_is_ptr(t))
> @@ -1832,13 +1835,15 @@ static void env_stack_pop_resolved(struct btf_verifier_env *env,
> u32 resolved_type_id,
> u32 resolved_size)
> {
> - u32 type_id = env->stack[--(env->top_stack)].type_id;
> + struct resolve_vertex *v = &env->stack[--(env->top_stack)];
> + u32 type_id = v->type_id;
> struct btf *btf = env->btf;
>
> type_id -= btf->start_id; /* adjust to local type id */
> btf->resolved_sizes[type_id] = resolved_size;
> btf->resolved_ids[type_id] = resolved_type_id;
> env->visit_states[type_id] = RESOLVED;
> + env->resolve_mode = v->parent_mode;
Other than datasec, could v->parent_mode and env->resolve_mode be different
while resolving? I would prefer to keep the 'env->resolve_mode = RESOLVE_TBD' in
btf_datasec_resolve() to make this special case clear.
> }
>
> static const struct resolve_vertex *env_stack_peak(struct btf_verifier_env *env)
> @@ -4541,7 +4546,6 @@ static int btf_datasec_resolve(struct btf_verifier_env *env,
> struct btf *btf = env->btf;
> u16 i;
>
> - env->resolve_mode = RESOLVE_TBD;
> for_each_vsi_from(i, v->next_member, v->t, vsi) {
> u32 var_type_id = vsi->type, type_id, type_size = 0;
> const struct btf_type *var_type = btf_type_by_id(env->btf,
next prev parent reply other threads:[~2023-05-17 6:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 12:15 [PATCH bpf-next] bpf: btf: restore resolve_mode when popping the resolve stack Lorenz Bauer
2023-05-15 19:26 ` Daniel Borkmann
2023-05-16 10:32 ` Lorenz Bauer
2023-05-17 6:26 ` Martin KaFai Lau [this message]
2023-05-17 9:01 ` Lorenz Bauer
2023-05-18 1:42 ` Martin KaFai Lau
2023-05-18 8:42 ` Lorenz Bauer
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=a29c604e-5a68-eed2-b581-0ad4687fda10@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lmb@isovalent.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yhs@fb.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.