linux-kernel - Re: [PATCH bpf-next 1/3] bpf: verifier: Store null elision decision in insn_aux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQ+eynNC0Hs0pd2adZX3Ryi3buAHkbvD3HT92Gg=ZJvDxA@mail.gmail.com>
Date: Wed, 22 Jan 2025 16:23:19 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Daniel Xu <dxu@...uu.xyz>
Cc: Daniel Borkmann <daniel@...earbox.net>, Alexei Starovoitov <ast@...nel.org>, 
	Andrii Nakryiko <andrii@...nel.org>, John Fastabend <john.fastabend@...il.com>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, Eddy Z <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, KP Singh <kpsingh@...nel.org>, 
	Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/3] bpf: verifier: Store null elision decision
 in insn_aux_data

On Mon, Jan 20, 2025 at 8:35 PM Daniel Xu <dxu@...uu.xyz> wrote:
>
> Save the null elision decision from verification so that it can be
> reused later during bpf_map_lookup_elem inlining. There's a generated
> jump that can be omitted if the null was elided.
>
> Signed-off-by: Daniel Xu <dxu@...uu.xyz>
> ---
>  include/linux/bpf_verifier.h | 4 ++++
>  kernel/bpf/verifier.c        | 4 +++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index 32c23f2a3086..1bcd6d66e546 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -515,6 +515,10 @@ struct bpf_map_ptr_state {
>         struct bpf_map *map_ptr;
>         bool poison;
>         bool unpriv;
> +       /* true if instruction is a bpf_map_lookup_elem() with statically
> +        * known in-bounds key.
> +        */
> +       bool inbounds;
>  };
>
>  /* Possible states for alu_state member. */
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 74525392714e..e83145c2260d 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -11265,8 +11265,10 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
>                 if (func_id == BPF_FUNC_map_lookup_elem &&
>                     can_elide_value_nullness(meta.map_ptr->map_type) &&
>                     meta.const_map_key >= 0 &&
> -                   meta.const_map_key < meta.map_ptr->max_entries)
> +                   meta.const_map_key < meta.map_ptr->max_entries) {
>                         ret_flag &= ~PTR_MAYBE_NULL;
> +                       env->insn_aux_data[insn_idx].map_ptr_state.inbounds = true;
> +               }

I don't think it handles the case where the same call insn
is used with const key and non-const/out-of-range.
insn_aux_data will be sticky and incorrect.

pw-bot: cr