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]

Date:   Wed, 16 Jan 2019 15:42:30 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Quentin Monnet <quentin.monnet@...ronome.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>, brouer@...hat.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

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).


> All map types are probed, as there is no specific rule telling which one
> could or could not be supported by a device in the future. All helpers
> are probed (but only for offload-able program types).
> 
> Caveat: as bpftool does not attempt to attach programs to the device at
> the moment, probes do not entirely reflect what the device accepts:
> typically, for Netronome's nfp, results will announce that TC cls
> offload is available even if support has been deactivated (with e.g.
> ethtool -K eth1 hw-tc-offload off).
> 
> v2:
> - All helpers are probed, whereas previous version would only probe the
>   ones compatible with an offload-able program type. This is because we
>   do not keep a default compatible program type for each helper anymore.



-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer