netdev - Re: [PATCH bpf-next v2] 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]

Date:   Thu, 13 Feb 2020 18:00:04 +0100
From:   "Eelco Chaudron" <echaudro@...hat.com>
To:     "Toke Høiland-Jørgensen" <toke@...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
Subject: Re: [PATCH bpf-next v2] libbpf: Add support for dynamic program
 attach target



On 13 Feb 2020, at 16:32, Toke Høiland-Jørgensen wrote:

> Eelco Chaudron <echaudro@...hat.com> writes:
>
>> 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)
>>
>> Signed-off-by: Eelco Chaudron <echaudro@...hat.com>
>
> Hmm, one question about the attach_prog_fd usage:
>
>> +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);
>
> This implies that no one would end up using fd 0 as a legitimate prog
> fd. This already seems to be the case for the existing code, but is 
> that
> really a safe assumption? Couldn't a caller that closes fd 0 (for
> instance while forking) end up having it reused? Seems like this could
> result in weird hard-to-debug bugs?


Yes, in theory, this can happen but it has nothing to do with this 
specific patch. The existing code already assumes that attach_prog_fd == 
0 means attach to a kernel function :(