netdev - Re: [PATCH bpf-next v1 04/19] bpf: allow loading of a bpf

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: <20200429005415.x2ocuctowbagpkaw@kafai-mbp>
Date:   Tue, 28 Apr 2020 17:54:15 -0700
From:   Martin KaFai Lau <kafai@...com>
To:     Yonghong Song <yhs@...com>
CC:     Andrii Nakryiko <andriin@...com>, <bpf@...r.kernel.org>,
        <netdev@...r.kernel.org>, Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>, <kernel-team@...com>
Subject: Re: [PATCH bpf-next v1 04/19] bpf: allow loading of a bpf_iter
 program

On Mon, Apr 27, 2020 at 01:12:39PM -0700, Yonghong Song wrote:
> A bpf_iter program is a tracing program with attach type
> BPF_TRACE_ITER. The load attribute
>   attach_btf_id
> is used by the verifier against a particular kernel function,
> e.g., __bpf_iter__bpf_map in our previous bpf_map iterator.
> 
> The program return value must be 0 for now. In the
> future, other return values may be used for filtering or
> teminating the iterator.
> 
> Signed-off-by: Yonghong Song <yhs@...com>
> ---
>  include/uapi/linux/bpf.h       |  1 +
>  kernel/bpf/verifier.c          | 20 ++++++++++++++++++++
>  tools/include/uapi/linux/bpf.h |  1 +
>  3 files changed, 22 insertions(+)
> 
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 4a6c47f3febe..f39b9fec37ab 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -215,6 +215,7 @@ enum bpf_attach_type {
>  	BPF_TRACE_FEXIT,
>  	BPF_MODIFY_RETURN,
>  	BPF_LSM_MAC,
> +	BPF_TRACE_ITER,
>  	__MAX_BPF_ATTACH_TYPE
>  };
>  
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 91728e0f27eb..fd36c22685d9 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -7074,6 +7074,11 @@ static int check_return_code(struct bpf_verifier_env *env)
>  			return 0;
>  		range = tnum_const(0);
>  		break;
> +	case BPF_PROG_TYPE_TRACING:
> +		if (env->prog->expected_attach_type != BPF_TRACE_ITER)
> +			return 0;
> +		range = tnum_const(0);
> +		break;
>  	default:
>  		return 0;
>  	}
> @@ -10454,6 +10459,7 @@ static int check_attach_btf_id(struct bpf_verifier_env *env)
>  	struct bpf_prog *tgt_prog = prog->aux->linked_prog;
>  	u32 btf_id = prog->aux->attach_btf_id;
>  	const char prefix[] = "btf_trace_";
> +	struct btf_func_model fmodel;
>  	int ret = 0, subprog = -1, i;
>  	struct bpf_trampoline *tr;
>  	const struct btf_type *t;
> @@ -10595,6 +10601,20 @@ static int check_attach_btf_id(struct bpf_verifier_env *env)
>  		prog->aux->attach_func_proto = t;
>  		prog->aux->attach_btf_trace = true;
>  		return 0;
> +	case BPF_TRACE_ITER:
> +		if (!btf_type_is_func(t)) {
> +			verbose(env, "attach_btf_id %u is not a function\n",
> +				btf_id);
> +			return -EINVAL;
> +		}
> +		t = btf_type_by_id(btf, t->type);
> +		if (!btf_type_is_func_proto(t))
Other than the type tests,
to ensure the attach_btf_id is a supported bpf_iter target,
should the prog be checked against the target list
("struct list_head targets") here also during the prog load time?

> +			return -EINVAL;
> +		prog->aux->attach_func_name = tname;
> +		prog->aux->attach_func_proto = t;
> +		ret = btf_distill_func_proto(&env->log, btf, t,
> +					     tname, &fmodel);
> +		return ret;
>  	default:
>  		if (!prog_extension)
>  			return -EINVAL;