| 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
| ||
|
Message-ID: <CAEf4Bzb_qyd9KbNU6=vs=H3Nbqt6QNNo++JVRCUrQ9aFW4psMA@mail.gmail.com>
Date: Mon, 10 Jul 2023 21:00:31 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: ast@...nel.org, andrii@...nel.org, martin.lau@...ux.dev,
razor@...ckwall.org, sdf@...gle.com, john.fastabend@...il.com,
kuba@...nel.org, dxu@...uu.xyz, joe@...ium.io, toke@...nel.org,
davem@...emloft.net, bpf@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next v4 4/8] libbpf: Add link-based API for tcx
On Mon, Jul 10, 2023 at 1:12 PM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> Implement tcx BPF link support for libbpf.
>
> The bpf_program__attach_fd() API has been refactored slightly in order to pass
> bpf_link_create_opts pointer as input.
>
> A new bpf_program__attach_tcx() has been added on top of this which allows for
> passing all relevant data via extensible struct bpf_tcx_opts.
>
> The program sections tcx/ingress and tcx/egress correspond to the hook locations
> for tc ingress and egress, respectively.
>
> For concrete usage examples, see the extensive selftests that have been
> developed as part of this series.
>
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> ---
> tools/lib/bpf/bpf.c | 19 ++++++++++--
> tools/lib/bpf/bpf.h | 5 ++++
> tools/lib/bpf/libbpf.c | 62 ++++++++++++++++++++++++++++++++++------
> tools/lib/bpf/libbpf.h | 16 +++++++++++
> tools/lib/bpf/libbpf.map | 1 +
> 5 files changed, 92 insertions(+), 11 deletions(-)
>
Pretty minor nits, I think ifindex move to be mandatory argument is
the most consequential, as it's an API. With that addressed, please
add my ack for next rev
Acked-by: Andrii Nakryiko <andrii@...nel.org>
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 3dfc43b477c3..d513c226b9aa 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -717,9 +717,9 @@ int bpf_link_create(int prog_fd, int target_fd,
> const struct bpf_link_create_opts *opts)
> {
> const size_t attr_sz = offsetofend(union bpf_attr, link_create);
> - __u32 target_btf_id, iter_info_len;
> + __u32 target_btf_id, iter_info_len, relative_id;
> + int fd, err, relative;
nit: maybe make these new vars local to the TCX cases branch below?
> union bpf_attr attr;
> - int fd, err;
>
> if (!OPTS_VALID(opts, bpf_link_create_opts))
> return libbpf_err(-EINVAL);
> @@ -781,6 +781,21 @@ int bpf_link_create(int prog_fd, int target_fd,
> if (!OPTS_ZEROED(opts, netfilter))
> return libbpf_err(-EINVAL);
> break;
> + case BPF_TCX_INGRESS:
> + case BPF_TCX_EGRESS:
> + relative = OPTS_GET(opts, tcx.relative_fd, 0);
> + relative_id = OPTS_GET(opts, tcx.relative_id, 0);
> + if (relative > 0 && relative_id)
> + return libbpf_err(-EINVAL);
> + if (relative_id) {
> + relative = relative_id;
> + attr.link_create.flags |= BPF_F_ID;
> + }
Well, I have the same nit as in the previous patch, this "relative =
relative_id" is both confusing because of naming asymmetry (no
relative_fd throws me off), and also unnecessary updating of the
state. link_create.flags |= BPF_F_ID is inevitable, but the rest can
be more straightforward, IMO
> + attr.link_create.tcx.relative_fd = relative;
> + attr.link_create.tcx.expected_revision = OPTS_GET(opts, tcx.expected_revision, 0);
> + if (!OPTS_ZEROED(opts, tcx))
> + return libbpf_err(-EINVAL);
> + break;
> default:
> if (!OPTS_ZEROED(opts, flags))
> return libbpf_err(-EINVAL);
[...]
> +struct bpf_link *
> +bpf_program__attach_tcx(const struct bpf_program *prog,
> + const struct bpf_tcx_opts *opts)
> +{
> + LIBBPF_OPTS(bpf_link_create_opts, link_create_opts);
> + __u32 relative_id, flags;
> + int ifindex, relative_fd;
> +
> + if (!OPTS_VALID(opts, bpf_tcx_opts))
> + return libbpf_err_ptr(-EINVAL);
> +
> + relative_id = OPTS_GET(opts, relative_id, 0);
> + relative_fd = OPTS_GET(opts, relative_fd, 0);
> + flags = OPTS_GET(opts, flags, 0);
> + ifindex = OPTS_GET(opts, ifindex, 0);
> +
> + /* validate we don't have unexpected combinations of non-zero fields */
> + if (!ifindex) {
> + pr_warn("prog '%s': target netdevice ifindex cannot be zero\n",
> + prog->name);
> + return libbpf_err_ptr(-EINVAL);
> + }
given ifindex is non-optional, then it makes more sense to have it as
a mandatory argument between prog and opts in
bpf_program__attach_tcx(), instead of as a field of an opts struct
> + if (relative_fd > 0 && relative_id) {
this asymmetrical check is a bit distracting. And also, if someone
specifies negative FD and positive ID, that's also a bad combo and we
shouldn't just ignore invalid FD, right? So I'd have a nice and clean
if (relative_fd && relative_id) { /* bad */ }
> + pr_warn("prog '%s': relative_fd and relative_id cannot be set at the same time\n",
> + prog->name);
> + return libbpf_err_ptr(-EINVAL);
> + }
> + if (relative_id)
> + flags |= BPF_F_ID;
I think bpf_link_create() will add this flag anyways, so can drop this
adjustment logic here?
> +
> + link_create_opts.tcx.expected_revision = OPTS_GET(opts, expected_revision, 0);
> + link_create_opts.tcx.relative_fd = relative_fd;
> + link_create_opts.tcx.relative_id = relative_id;
> + link_create_opts.flags = flags;
> +
> + /* target_fd/target_ifindex use the same field in LINK_CREATE */
> + return bpf_program_attach_fd(prog, ifindex, "tc", &link_create_opts);
s/tc/tcx/ ?
> }
>
> struct bpf_link *bpf_program__attach_freplace(const struct bpf_program *prog,
> @@ -11917,11 +11956,16 @@ struct bpf_link *bpf_program__attach_freplace(const struct bpf_program *prog,
> }
>
> if (target_fd) {
> + LIBBPF_OPTS(bpf_link_create_opts, target_opts);
> +
> btf_id = libbpf_find_prog_btf_id(attach_func_name, target_fd);
> if (btf_id < 0)
> return libbpf_err_ptr(btf_id);
>
> - return bpf_program__attach_fd(prog, target_fd, btf_id, "freplace");
> + target_opts.target_btf_id = btf_id;
> +
> + return bpf_program_attach_fd(prog, target_fd, "freplace",
> + &target_opts);
> } else {
> /* no target, so use raw_tracepoint_open for compatibility
> * with old kernels
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 10642ad69d76..33f60a318e81 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -733,6 +733,22 @@ LIBBPF_API struct bpf_link *
> bpf_program__attach_netfilter(const struct bpf_program *prog,
> const struct bpf_netfilter_opts *opts);
>
> +struct bpf_tcx_opts {
> + /* size of this struct, for forward/backward compatibility */
> + size_t sz;
> + int ifindex;
is ifindex optional or it's expected to always be specified? If the
latter, then I'd move ifindex out of opts and make it second arg of
bpf_program__attach_tcx, between prog and opts
> + __u32 flags;
> + __u32 relative_fd;
> + __u32 relative_id;
> + __u64 expected_revision;
> + size_t :0;
> +};
> +#define bpf_tcx_opts__last_field expected_revision
> +
> +LIBBPF_API struct bpf_link *
> +bpf_program__attach_tcx(const struct bpf_program *prog,
> + const struct bpf_tcx_opts *opts);
> +
> struct bpf_map;
>
> LIBBPF_API struct bpf_link *bpf_map__attach_struct_ops(const struct bpf_map *map);
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index a95d39bbef90..2a2db5c78048 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -397,4 +397,5 @@ LIBBPF_1.3.0 {
> bpf_obj_pin_opts;
> bpf_program__attach_netfilter;
> bpf_prog_detach_opts;
> + bpf_program__attach_tcx;
heh, now we definitely screwed up sorting ;)
> } LIBBPF_1.2.0;
> --
> 2.34.1
>
Powered by blists - more mailing lists