[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4Bzb3XbGx+N5yrYELNAkaABP9fyifAQhTP1VHSvVycG36TQ@mail.gmail.com>
Date: Thu, 15 Aug 2024 10:15:22 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Juntong Deng <juntong.deng@...look.com>
Cc: ast@...nel.org, daniel@...earbox.net, john.fastabend@...il.com,
andrii@...nel.org, martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org,
yonghong.song@...ux.dev, kpsingh@...nel.org, sdf@...ichev.me,
haoluo@...gle.com, jolsa@...nel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next 1/2] bpf: Make the pointer returned by iter next
method valid
On Thu, Aug 15, 2024 at 9:11 AM Juntong Deng <juntong.deng@...look.com> wrote:
>
> Currently we cannot pass the pointer returned by iter next method as
> argument to KF_TRUSTED_ARGS kfuncs, because the pointer returned by
> iter next method is not "valid".
>
> This patch sets the pointer returned by iter next method to be valid.
>
> This is based on the fact that if the iterator is implemented correctly,
> then the pointer returned from the iter next method should be valid.
>
> This does not make NULL pointer valid. If the iter next method has
> KF_RET_NULL flag, then the verifier will ask the ebpf program to
> check NULL pointer.
>
> Signed-off-by: Juntong Deng <juntong.deng@...look.com>
> ---
> kernel/bpf/verifier.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index ebec74c28ae3..35a7b7c6679c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -12832,6 +12832,10 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> /* For mark_ptr_or_null_reg, see 93c230e3f5bd6 */
> regs[BPF_REG_0].id = ++env->id_gen;
> }
> +
> + if (is_iter_next_kfunc(&meta))
> + regs[BPF_REG_0].type |= PTR_TRUSTED;
> +
It seems a bit too generic to always assign PTR_TRUSTED to anything
returned from any iterator. Let's maybe add KF_RET_TRUSTED or
KF_ITER_TRUSTED or something along those lines to mark such iter_next
kfuncs explicitly?
For the numbers iterator, for instance, this PTR_TRUSTED makes no sense.
> mark_btf_func_reg_size(env, BPF_REG_0, sizeof(void *));
> if (is_kfunc_acquire(&meta)) {
> int id = acquire_reference_state(env, insn_idx);
> --
> 2.39.2
>
Powered by blists - more mailing lists