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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux