[PATCH bpf-next v3 03/10] bpf: lsm: Introduce types for eBPF based LSM

[Alexei Starovoitov]

On Thu, Jan 23, 2020 at 07:24:33AM -0800, KP Singh wrote:
> +
> +static const struct bpf_func_proto *get_bpf_func_proto(
> +	enum bpf_func_id func_id, const struct bpf_prog *prog)
> +{
> +	switch (func_id) {
> +	case BPF_FUNC_map_lookup_elem:
> +		return &bpf_map_lookup_elem_proto;
> +	case BPF_FUNC_get_current_pid_tgid:
> +		return &bpf_get_current_pid_tgid_proto;
> +	default:
> +		return NULL;
> +	}
> +}
> +
> +const struct bpf_verifier_ops lsm_verifier_ops = {
> +	.get_func_proto = get_bpf_func_proto,
> +};

Why artificially limit it like this?
It will cause a lot of churn in the future. Like allowing map update and
delete, in addition to lookup, will be an obvious next step.
I think allowing tracing_func_proto() from the start is cleaner.