netdev - Re: [PATCH bpf-next v4 8/9] tools: bpftool: add probes for a network device

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: <0fd8226f-52b5-39b7-b80c-e79f47498541@netronome.com>
Date:   Wed, 16 Jan 2019 14:59:28 +0000
From:   Quentin Monnet <quentin.monnet@...ronome.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        oss-drivers@...ronome.com,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Eric Leblond <eric@...it.org>,
        Toke Høiland-Jørgensen <toke@...e.dk>
Subject: Re: [PATCH bpf-next v4 8/9] tools: bpftool: add probes for a network
 device

2019-01-16 15:42 UTC+0100 ~ Jesper Dangaard Brouer <brouer@...hat.com>
> On Wed, 16 Jan 2019 14:21:18 +0000
> Quentin Monnet <quentin.monnet@...ronome.com> wrote:
> 
>> bpftool gained support for probing the current system in order to see
>> what program and map types, and what helpers are available on that
>> system. This patch adds the possibility to pass an interface index to
>> libbpf (and hence to the kernel) when trying to load the programs or to
>> create the maps, in order to see what items a given network device can
>> support.
>>
>> A new keyword "dev <ifname>" can be used as an alternative to "kernel"
>> to indicate that the given device should be tested. If no target ("dev"
>> or "kernel") is specified bpftool defaults to probing the kernel.
>>
>> Sample output:
>>
>>     # bpftool -p feature probe dev lo
>>     {
>>         "syscall_config": {
>>             "have_bpf_syscall": true
>>         },
>>         "program_types": {
>>             "have_sched_cls_prog_type": false,
>>             "have_xdp_prog_type": false
>>         },
>>         ...
>>     }
>>
>> As the target is a network device, /proc/ parameters and kernel
>> configuration are NOT dumped. Availability of the bpf() syscall is
>> still probed, so we can return early if that syscall is not usable
>> (since there is no point in attempting the remaining probes in this
>> case).
>>
>> Among the program types, only the ones that can be offloaded are probed.
> 
> Do you imagine we (later) can use this probe dev interface for probing
> e.g. what XDP actions a given driver supports?  and e.g. if driver have
> data_meta support.
> 
> Use-case: I've very interested in finding a solution for probing for
> XDP_REDIRECT support, as Suricata need this information, so it can
> choose to fallback to offloading elefant flows via TC-cls_bpf (if
> XDP_REDIRECT is not avail).

Hi Jesper!

For me, the question is rather a matter of how to extract the info from
the kernel (or driver in that case). If the information can be made
available somehow, sure, bpftool seems to be one of the best candidates
to use it and dump the value.

Quentin