netdev - Re: [PATCH bpf-next v5 04/13] bpf: net_sched: Add basic bpf qdisc kfuncs

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+ayU=H0gzFdh5Yfx=Aya4PXUJYvQoOXb+4=wsgmnnDQQ@mail.gmail.com>
Date: Fri, 14 Mar 2025 13:14:08 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Amery Hung <ameryhung@...il.com>
Cc: Network Development <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, 
	Martin KaFai Lau <martin.lau@...nel.org>, Jakub Kicinski <kuba@...nel.org>, 
	Eric Dumazet <edumazet@...gle.com>, Cong Wang <xiyou.wangcong@...il.com>, 
	Jamal Hadi Salim <jhs@...atatu.com>, Kui-Feng Lee <sinquersw@...il.com>, 
	Toke Høiland-Jørgensen <toke@...hat.com>, 
	Jiri Pirko <jiri@...nulli.us>, Stanislav Fomichev <stfomichev@...il.com>, 
	ekarani.silvestre@....ufcg.edu.br, yangpeihao@...u.edu.cn, 
	Peilin Ye <yepeilin.cs@...il.com>, Kernel Team <kernel-team@...a.com>
Subject: Re: [PATCH bpf-next v5 04/13] bpf: net_sched: Add basic bpf qdisc kfuncs

On Thu, Mar 13, 2025 at 12:03 PM Amery Hung <ameryhung@...il.com> wrote:
>
> From: Amery Hung <amery.hung@...edance.com>
>
> Add basic kfuncs for working on skb in qdisc.
>
> Both bpf_qdisc_skb_drop() and bpf_kfree_skb() can be used to release
> a reference to an skb. However, bpf_qdisc_skb_drop() can only be called
> in .enqueue where a to_free skb list is available from kernel to defer
> the release. bpf_kfree_skb() should be used elsewhere. It is also used
> in bpf_obj_free_fields() when cleaning up skb in maps and collections.
>
> bpf_skb_get_hash() returns the flow hash of an skb, which can be used
> to build flow-based queueing algorithms.
>
> Finally, allow users to create read-only dynptr via bpf_dynptr_from_skb().
>
> Signed-off-by: Amery Hung <amery.hung@...edance.com>
> ---
>  include/linux/bpf.h         |  1 +
>  kernel/bpf/bpf_struct_ops.c |  2 +
>  net/sched/bpf_qdisc.c       | 93 ++++++++++++++++++++++++++++++++++++-
>  3 files changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 463e922cb0f5..d3b0c4ccaebf 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -1826,6 +1826,7 @@ struct bpf_struct_ops {
>         void *cfi_stubs;
>         struct module *owner;
>         const char *name;
> +       const struct btf_type *type;
>         struct btf_func_model func_models[BPF_STRUCT_OPS_MAX_NR_MEMBERS];
>  };

there is an alternative to this...

> +static int bpf_qdisc_kfunc_filter(const struct bpf_prog *prog, u32 kfunc_id)
> +{
> +       if (bpf_Qdisc_ops.type != btf_type_by_id(prog->aux->attach_btf,
> +                                                prog->aux->attach_btf_id))
> +               return 0;
> +
> +       /* Skip the check when prog->attach_func_name is not yet available
> +        * during check_cfg().
> +        */
> +       if (!btf_id_set8_contains(&qdisc_kfunc_ids, kfunc_id) ||
> +           !prog->aux->attach_func_name)
> +               return 0;
> +
> +       if (bpf_struct_ops_prog_moff(prog) == offsetof(struct Qdisc_ops, enqueue)) {
> +               if (btf_id_set_contains(&qdisc_enqueue_kfunc_set, kfunc_id))
> +                       return 0;
> +       }

Instead of logic in this patch and patch 2,
I think it's cleaner to do:
https://lore.kernel.org/all/AM6PR03MB50804BE76B752350307B6B4C99C22@AM6PR03MB5080.eurprd03.prod.outlook.com/

then in this patch it will be

if (prog->aux->st_ops != &bpf_Qdisc_ops)

and instead of unchecked array accesses in bpf_struct_ops_prog_moff()
it will be prog->aux->attach_st_ops_member_off

Also see flag based approach in Juntong's patch 3+4.
imo it looks cleaner (more extensible with more checks per st_ops hook)
than offsetof() approach above.