[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0cf37771-f23e-e165-8c73-8cb5fb3e7f22@fb.com>
Date: Wed, 16 Oct 2019 19:50:06 +0000
From: Alexei Starovoitov <ast@...com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>,
Alexei Starovoitov <ast@...nel.org>
CC: "David S. Miller" <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
"x86@...nel.org" <x86@...nel.org>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH v3 bpf-next 04/11] bpf: add attach_btf_id attribute to
program load
On 10/16/19 12:45 PM, Andrii Nakryiko wrote:
> On Wed, Oct 16, 2019 at 4:15 AM Alexei Starovoitov <ast@...nel.org> wrote:
>>
>> Add attach_btf_id attribute to prog_load command.
>> It's similar to existing expected_attach_type attribute which is
>> used in several cgroup based program types.
>> Unfortunately expected_attach_type is ignored for
>> tracing programs and cannot be reused for new purpose.
>> Hence introduce attach_btf_id to verify bpf programs against
>> given in-kernel BTF type id at load time.
>> It is strictly checked to be valid for raw_tp programs only.
>> In a later patches it will become:
>> btf_id == 0 semantics of existing raw_tp progs.
>> btd_id > 0 raw_tp with BTF and additional type safety.
>>
>> Signed-off-by: Alexei Starovoitov <ast@...nel.org>
>> Acked-by: Andrii Nakryiko <andriin@...com>
>> ---
>> include/linux/bpf.h | 1 +
>> include/uapi/linux/bpf.h | 1 +
>> kernel/bpf/syscall.c | 18 ++++++++++++++----
>> tools/include/uapi/linux/bpf.h | 1 +
>> 4 files changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index 282e28bf41ec..f916380675dd 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -375,6 +375,7 @@ struct bpf_prog_aux {
>> u32 id;
>> u32 func_cnt; /* used by non-func prog as the number of func progs */
>> u32 func_idx; /* 0 for non-func prog, the index in func array for func prog */
>> + u32 attach_btf_id; /* in-kernel BTF type id to attach to */
>> bool verifier_zext; /* Zero extensions has been inserted by verifier. */
>> bool offload_requested;
>> struct bpf_prog **func;
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index a65c3b0c6935..3bb2cd1de341 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -420,6 +420,7 @@ union bpf_attr {
>> __u32 line_info_rec_size; /* userspace bpf_line_info size */
>> __aligned_u64 line_info; /* line info */
>> __u32 line_info_cnt; /* number of bpf_line_info records */
>> + __u32 attach_btf_id; /* in-kernel BTF type id to attach to */
>> };
>>
>> struct { /* anonymous struct used by BPF_OBJ_* commands */
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index 82eabd4e38ad..b56c482c9760 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -23,6 +23,7 @@
>> #include <linux/timekeeping.h>
>> #include <linux/ctype.h>
>> #include <linux/nospec.h>
>> +#include <uapi/linux/btf.h>
>>
>> #define IS_FD_ARRAY(map) ((map)->map_type == BPF_MAP_TYPE_PROG_ARRAY || \
>> (map)->map_type == BPF_MAP_TYPE_PERF_EVENT_ARRAY || \
>> @@ -1565,8 +1566,9 @@ static void bpf_prog_load_fixup_attach_type(union bpf_attr *attr)
>> }
>>
>> static int
>> -bpf_prog_load_check_attach_type(enum bpf_prog_type prog_type,
>> - enum bpf_attach_type expected_attach_type)
>> +bpf_prog_load_check_attach(enum bpf_prog_type prog_type,
>> + enum bpf_attach_type expected_attach_type,
>> + u32 btf_id)
>> {
>> switch (prog_type) {
>> case BPF_PROG_TYPE_CGROUP_SOCK:
>> @@ -1608,13 +1610,19 @@ bpf_prog_load_check_attach_type(enum bpf_prog_type prog_type,
>> default:
>> return -EINVAL;
>> }
>> + case BPF_PROG_TYPE_RAW_TRACEPOINT:
>> + if (btf_id > BTF_MAX_TYPE)
>> + return -EINVAL;
>> + return 0;
>> default:
>> + if (btf_id)
>> + return -EINVAL;
>
> this is minor issue, feel free to fix in a follow up patch, but this
> check should be done for all cases but BPF_PROG_TYPE_RAW_TRACEPOINT,
> not just for default (default will ignore a bunch of cgroup attach
> types).
right. good point. will fix in follow up if there are no issues in the
rest of patches.
Powered by blists - more mailing lists