netdev - Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP

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

Message-ID: <e6c8bac5-963e-0391-7697-2044bb428de0@iogearbox.net>
Date:   Thu, 13 Dec 2018 12:52:38 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Stanislav Fomichev <sdf@...ichev.me>
Cc:     Edward Cree <ecree@...arflare.com>,
        Stanislav Fomichev <sdf@...gle.com>, netdev@...r.kernel.org,
        davem@...emloft.net, ast@...nel.org, quentin.monnet@...ronome.com
Subject: Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that
 depend on CONFIG_CGROUP_BPF

On 12/13/2018 07:06 AM, Alexei Starovoitov wrote:
> On Wed, Dec 12, 2018 at 02:32:01PM -0800, Stanislav Fomichev wrote:
>>
>> To summarize, I like your idea about doing runtime tests and I think I
>> can make it work quite nicely without any config_disabled ugliness by
>> looking at the prog_type of each test.
>> I can send an RFC patch series out if there still a small chance you could
>> take it, but if you've already set you mind, I'd just keep them
>> internally. So let me know if you have a hard NACK on the runtime probing
>> approach or there is still some wiggle room.
> 
> If there is no uapi/bpf.h change, it's likely fine.
> Like if test_verifier tries to load 'foo() {return 0;}' prog
> for the .prog_type in the test that failed to confirm that
> such prog type is supported by the kernel...
> that is fine, since no extra prog_loads are happening for the default case.

I think this would kind of go along the lines of what Quentin is working on.
Idea [0] is to consolidate effort into bpftool so that one can do something
like `bpftool kernel probe` and it generates a header file with CONFIG_*
defines for features where bpftool was able to successfully probe the
underlying kernel with. This would allow developers to include this header
generation as part of the build workflow and avoid having to implement
similar probing mechanism in various projects over and over again which aim
to run on different kernel versions. I'm wondering whether it would make sense
to split the probing part and put it into libbpf where then bpftool is only
responsible to call the API and write out the defines? That way, the runtime
probing could potentially be reused for selftests as well?

Thanks,
Daniel

 [0] slide 8,12: http://vger.kernel.org/lpc_bpf2018_talks/qmo-bpf-slides-v2.pdf