netdev - Re: [PATCH v2 bpf-next 6/9] libbpf: use negative fd to specify missing BTF

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:   Tue, 2 Jul 2019 15:57:33 -0700
From:   Stanislav Fomichev <sdf@...ichev.me>
To:     Andrii Nakryiko <andriin@...com>
Cc:     andrii.nakryiko@...il.com, netdev@...r.kernel.org,
        bpf@...r.kernel.org, ast@...com, daniel@...earbox.net,
        kernel-team@...com
Subject: Re: [PATCH v2 bpf-next 6/9] libbpf: use negative fd to specify
 missing BTF

On 05/29, Andrii Nakryiko wrote:
> 0 is a valid FD, so it's better to initialize it to -1, as is done in
> other places. Also, technically, BTF type ID 0 is valid (it's a VOID
> type), so it's more reliable to check btf_fd, instead of
> btf_key_type_id, to determine if there is any BTF associated with a map.
> 
> Acked-by: Song Liu <songliubraving@...com>
> Signed-off-by: Andrii Nakryiko <andriin@...com>
> ---
>  tools/lib/bpf/libbpf.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index c972fa10271f..a27a0351e595 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -1751,7 +1751,7 @@ bpf_object__create_maps(struct bpf_object *obj)
>  		create_attr.key_size = def->key_size;
>  		create_attr.value_size = def->value_size;
>  		create_attr.max_entries = def->max_entries;
> -		create_attr.btf_fd = 0;
> +		create_attr.btf_fd = -1;
>  		create_attr.btf_key_type_id = 0;
>  		create_attr.btf_value_type_id = 0;
>  		if (bpf_map_type__is_map_in_map(def->type) &&
> @@ -1765,11 +1765,11 @@ bpf_object__create_maps(struct bpf_object *obj)
>  		}
>  
>  		*pfd = bpf_create_map_xattr(&create_attr);
> -		if (*pfd < 0 && create_attr.btf_key_type_id) {
> +		if (*pfd < 0 && create_attr.btf_fd >= 0) {
>  			cp = libbpf_strerror_r(errno, errmsg, sizeof(errmsg));
>  			pr_warning("Error in bpf_create_map_xattr(%s):%s(%d). Retrying without BTF.\n",
>  				   map->name, cp, errno);
> -			create_attr.btf_fd = 0;
> +			create_attr.btf_fd = -1;
This breaks libbpf compatibility with the older kernels. If the kernel
doesn't know about btf_fd and we set it to -1, then CHECK_ATTR
fails :-(

Any objections to converting BTF retries to bpf_capabilities and then
knowingly passing bft_fd==0 or proper fd?

>  			create_attr.btf_key_type_id = 0;
>  			create_attr.btf_value_type_id = 0;
>  			map->btf_key_type_id = 0;
> @@ -2053,6 +2053,9 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
>  	char *log_buf;
>  	int ret;
>  
> +	if (!insns || !insns_cnt)
> +		return -EINVAL;
> +
>  	memset(&load_attr, 0, sizeof(struct bpf_load_program_attr));
>  	load_attr.prog_type = prog->type;
>  	load_attr.expected_attach_type = prog->expected_attach_type;
> @@ -2063,7 +2066,7 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
>  	load_attr.license = license;
>  	load_attr.kern_version = kern_version;
>  	load_attr.prog_ifindex = prog->prog_ifindex;
> -	load_attr.prog_btf_fd = prog->btf_fd >= 0 ? prog->btf_fd : 0;
> +	load_attr.prog_btf_fd = prog->btf_fd;
>  	load_attr.func_info = prog->func_info;
>  	load_attr.func_info_rec_size = prog->func_info_rec_size;
>  	load_attr.func_info_cnt = prog->func_info_cnt;
> @@ -2072,8 +2075,6 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
>  	load_attr.line_info_cnt = prog->line_info_cnt;
>  	load_attr.log_level = prog->log_level;
>  	load_attr.prog_flags = prog->prog_flags;
> -	if (!load_attr.insns || !load_attr.insns_cnt)
> -		return -EINVAL;
>  
>  retry_load:
>  	log_buf = malloc(log_buf_size);
> -- 
> 2.17.1
>