Re: [PATCH v3 bpf-next 04/11] bpf: add attach_btf_id attribute to program load

[Alexei Starovoitov <ast@fb.com>]

On 10/16/19 12:45 PM, Andrii Nakryiko wrote:
> On Wed, Oct 16, 2019 at 4:15 AM Alexei Starovoitov <ast@kernel.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@kernel.org>
>> Acked-by: Andrii Nakryiko <andriin@fb.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.