netdev - Re: [PATCH bpf-next v4 2/3] libbpf: Add support for dynamic program attach target

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: <877e0jam7z.fsf@cloudflare.com>
Date:   Tue, 18 Feb 2020 16:34:08 +0000
From:   Jakub Sitnicki <jakub@...udflare.com>
To:     Eelco Chaudron <echaudro@...hat.com>
Cc:     bpf@...r.kernel.org, davem@...emloft.net, netdev@...r.kernel.org,
        ast@...nel.org, daniel@...earbox.net, kafai@...com,
        songliubraving@...com, yhs@...com, andriin@...com, toke@...hat.com
Subject: Re: [PATCH bpf-next v4 2/3] libbpf: Add support for dynamic program attach target

Hey Eelco,

On Mon, Feb 17, 2020 at 12:43 PM GMT, Eelco Chaudron wrote:
> Currently when you want to attach a trace program to a bpf program
> the section name needs to match the tracepoint/function semantics.
>
> However the addition of the bpf_program__set_attach_target() API
> allows you to specify the tracepoint/function dynamically.
>
> The call flow would look something like this:
>
>   xdp_fd = bpf_prog_get_fd_by_id(id);
>   trace_obj = bpf_object__open_file("func.o", NULL);
>   prog = bpf_object__find_program_by_title(trace_obj,
>                                            "fentry/myfunc");
>   bpf_program__set_expected_attach_type(prog, BPF_TRACE_FENTRY);
>   bpf_program__set_attach_target(prog, xdp_fd,
>                                  "xdpfilt_blk_all");
>   bpf_object__load(trace_obj)
>
> Acked-by: Toke Høiland-Jørgensen <toke@...hat.com>
> Signed-off-by: Eelco Chaudron <echaudro@...hat.com>
> ---
>  tools/lib/bpf/libbpf.c   |   34 ++++++++++++++++++++++++++++++----
>  tools/lib/bpf/libbpf.h   |    4 ++++
>  tools/lib/bpf/libbpf.map |    2 ++
>  3 files changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 514b1a524abb..0c25d78fb5d8 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[...]

> @@ -8132,6 +8133,31 @@ void bpf_program__bpil_offs_to_addr(struct bpf_prog_info_linear *info_linear)
>  	}
>  }
>
> +int bpf_program__set_attach_target(struct bpf_program *prog,
> +				   int attach_prog_fd,
> +				   const char *attach_func_name)
> +{
> +	int btf_id;
> +
> +	if (!prog || attach_prog_fd < 0 || !attach_func_name)
> +		return -EINVAL;
> +
> +	if (attach_prog_fd)
> +		btf_id = libbpf_find_prog_btf_id(attach_func_name,
> +						 attach_prog_fd);
> +	else
> +		btf_id = __find_vmlinux_btf_id(prog->obj->btf_vmlinux,
> +					       attach_func_name,
> +					       prog->expected_attach_type);
> +
> +	if (btf_id <= 0)
> +		return btf_id;

Looks like we can get 0 as return value on both error and success
(below)?  Is that intentional?

> +
> +	prog->attach_btf_id = btf_id;
> +	prog->attach_prog_fd = attach_prog_fd;
> +	return 0;
> +}
> +
>  int parse_cpu_mask_str(const char *s, bool **mask, int *mask_sz)
>  {
>  	int err = 0, n, len, start, end = -1;

[...]