netdev - Re: [PATCH bpf-next v5 9/9] selftest/bpf: Implement tests for bpftool gen min_core

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Feb 2022 11:50:21 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Mauricio Vásquez Bernal <mauricio@...volk.io>
Cc:     Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Quentin Monnet <quentin@...valent.com>,
        Rafael David Tinoco <rafaeldtinoco@...il.com>,
        Lorenzo Fontana <lorenzo.fontana@...stic.co>,
        Leonardo Di Donato <leonardo.didonato@...stic.co>
Subject: Re: [PATCH bpf-next v5 9/9] selftest/bpf: Implement tests for bpftool
 gen min_core_btf

On Fri, Jan 28, 2022 at 3:23 PM Mauricio Vásquez Bernal
<mauricio@...volk.io> wrote:
>
> On Fri, Jan 28, 2022 at 5:33 PM Mauricio Vásquez <mauricio@...volk.io> wrote:
> >
> > This commit implements some integration tests for "BTFGen". The goal
> > of such tests is to verify that the generated BTF file contains the
> > expected types.
> >
>
> This is not an exhaustive list of test cases. I'm not sure if this is
> the approach we should follow to implement such tests, it seems to me
> that checking each generated BTF file by hand is a lot of work but I
> don't have other ideas to simplify it.
>
> I considered different options to write these tests:
> 1. Use core_reloc_types.h to create a "source" BTF file with a lot of
> types, then run BTFGen for all test_core_reloc_*.o files and use the
> generated BTF file as btf_src_file in core_reloc.c. In other words,
> re-run all test_core_reloc tests using a generated BTF file as source
> instead of the "btf__core_reloc_" #name ".o" one. I think this test is
> great because it tests the full functionality and actually checks that
> the programs are able to run using the generated file. The problem is
> how do we test that the BTFGen is creating an optimized file? Just
> copying the source file without any modification will make all those
> tests pass. We could check that the generated file is small (by
> checking the size or the number of types) but it doesn't seem a very
> reliable approach to me.

I think this second run after minimizing BTF is a good idea. I
wouldn't bother to check for "minimal BTF" for this case.

> 2. We could write some .c files with the types we expect to have on
> the generated file and compare it with the generated file. The issue
> here is that comparing those BTF files doesn't seem to be too
> trivial...

But I would add few realistic examples that use various combinations
of CO-RE relocations against Linux types. Then minimize BTF and
validate that BTF is what we expect.

As for how to compare BTFs. I've been wanting to do something like
btf__normalize() API to renumber and resort all the BTF types into
some "canonical" order, so that two BTFs can be actually compared and
diffed. It might be finally the time to do that.

The big complication is your decision to dump all the fields of types
that are used by type-based relocations. I'm not convinced that's the
best way to do this. I'd keep empty struct/union for such cases,
actually. That would minimize the number of types and thus BTF in
general. It also will simplify the logic of emitting minimized BTF a
bit (all_types checks won't be necessary, I think).

As I also mentioned in previous patches, for types that are only
referenced through pointer, I'd emit FWD declaration only. Or at best
empty struct/union.

With all that, after btf__minimize() operation, comparing BTFs would
be actually pretty easy, because we'll know the order of each type, so
using the
VALIDATE_RAW_BTF() (see prog_tests/btf_dedup_split.c) the tests will
be easy and clean.

One last thing, let's not add a new test binary (test_bpftool), let's
keep adding more tests into test_progs.

>
> Do you have any suggestions about it? Thanks!