netdev - Re: [RFC PATCH bpf-next 7/9] selftests/bpf: add CO-RE relo test for TYPE_ID_LOCAL/TYPE_ID

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] [day] [month] [year] [list]

Message-ID: <CAEf4BzaY174YV3wwJsYrHG-rYWp-to0DOxj65L7fGB12vWJLtQ@mail.gmail.com>
Date:   Thu, 6 Aug 2020 17:11:39 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [RFC PATCH bpf-next 7/9] selftests/bpf: add CO-RE relo test for TYPE_ID_LOCAL/TYPE_ID_TARGET

On Thu, Aug 6, 2020 at 5:10 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Thu, Aug 06, 2020 at 04:48:27PM -0700, Andrii Nakryiko wrote:
> > On Thu, Aug 6, 2020 at 3:30 PM Alexei Starovoitov
> > <alexei.starovoitov@...il.com> wrote:
> > >
> > > On Tue, Aug 04, 2020 at 11:24:07AM -0700, Andrii Nakryiko wrote:
> > > > +
> > > > +SEC("raw_tracepoint/sys_enter")
> > > > +int test_core_type_id(void *ctx)
> > > > +{
> > > > +     struct core_reloc_type_id_output *out = (void *)&data.out;
> > > > +
> > > > +     out->local_anon_struct = bpf_core_type_id_local(struct { int marker_field; });
> > > > +     out->local_anon_union = bpf_core_type_id_local(union { int marker_field; });
> > > > +     out->local_anon_enum = bpf_core_type_id_local(enum { MARKER_ENUM_VAL = 123 });
> > > > +     out->local_anon_func_proto_ptr = bpf_core_type_id_local(_Bool(*)(int));
> > > > +     out->local_anon_void_ptr = bpf_core_type_id_local(void *);
> > > > +     out->local_anon_arr = bpf_core_type_id_local(_Bool[47]);
> > > > +
> > > > +     out->local_struct = bpf_core_type_id_local(struct a_struct);
> > > > +     out->local_union = bpf_core_type_id_local(union a_union);
> > > > +     out->local_enum = bpf_core_type_id_local(enum an_enum);
> > > > +     out->local_int = bpf_core_type_id_local(int);
> > > > +     out->local_struct_typedef = bpf_core_type_id_local(named_struct_typedef);
> > > > +     out->local_func_proto_typedef = bpf_core_type_id_local(func_proto_typedef);
> > > > +     out->local_arr_typedef = bpf_core_type_id_local(arr_typedef);
> > > > +
> > > > +     out->targ_struct = bpf_core_type_id_kernel(struct a_struct);
> > > > +     out->targ_union = bpf_core_type_id_kernel(union a_union);
> > > > +     out->targ_enum = bpf_core_type_id_kernel(enum an_enum);
> > > > +     out->targ_int = bpf_core_type_id_kernel(int);
> > > > +     out->targ_struct_typedef = bpf_core_type_id_kernel(named_struct_typedef);
> > > > +     out->targ_func_proto_typedef = bpf_core_type_id_kernel(func_proto_typedef);
> > > > +     out->targ_arr_typedef = bpf_core_type_id_kernel(arr_typedef);
> > >
> > > bpf_core_type_id_kernel() returns btf_id of the type in vmlinux BTF or zero,
> > > so what is the point of above tests? All targ_* will be zero.
> > > Should the test find a type that actually exists in the kernel?
> > > What am I missing?
> >
> > Probably, that for almost all core_reloc tests, "kernel BTF" comes
> > from specially-crafted BTFs, like btf__core_reloc_type_id*.c for this
> > set of tests. Only one core_reloc sub-test actually loads real kernel
> > BTF, for all others we have a "controlled environment" set up.
>
> ahh. right.
>
> > But on another note. I opted to make all type-based relocations to
> > return 0 if target type is not found, but now I'm thinking that maybe
> > for TYPE_SIZE and TYPE_ID_KERNEL we should fail them, just like
> > field-based ones, if type is not found. Makes it harder to miss that
> > something changed in the new kernel version. WDYT?
>
> makes sense to me. If we ever need non-failing type_id_kernel() we can
> add it later, right?

Right. Plus you can always "guard" it with bpf_core_type_exists()
check, just like we do for field accesses, if the field might not
exist.