netdev - Re: [RFC PATCH bpf-next 0/4] tools/bpf: bpftool: add net support

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, 5 Sep 2018 19:51:09 +0200
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Yonghong Song <yhs@...com>
Cc:     <ast@...com>, <daniel@...earbox.net>, <netdev@...r.kernel.org>,
        <kernel-team@...com>
Subject: Re: [RFC PATCH bpf-next 0/4] tools/bpf: bpftool: add net support

On Mon, 3 Sep 2018 11:26:43 -0700, Yonghong Song wrote:
> The functionality to dump network driver and tc related bpf programs
> are added. Currently, users can already use "ip link show <dev>"
> and "tc filter show dev <dev> ..." to dump bpf program attachment
> information for xdp programs and tc bpf programs.
> The implementation here allows bpftool as a central place for
> bpf introspection and users do not need to revert to other tools.
> Also, we can make command simpler to dump bpf related information,
> e.g., "bpftool net" is able to dump all xdp and tc bpf programs.

Why not implement this best-effort, unreliable (name spaces) additional
output the same way we added bpffs support, make it a flag to existing
list commands?

My knee jerk reaction is that this is duplication of work.  iproute2 can
show us the filters and xdp programs very easily.  Will we add programs
attached to sockets as well?  And lwtunnels?  bpfilter?

Would you be able to give us a convincing user scenario?  What kind of
information is the user looking for?  Are there going to be other
sub-commands to the 'net' object?

> For example,
> 
>   $ bpftool net
>   xdp [
>   ]
>   netdev_filters [
>   ifindex 2 name handle_icmp flags direct-action flags_gen [not_in_hw ]

How do you handle shared blocks here?  Does the user really care about
the flags?  What about ordering of filters?

>             prog_id 3194 tag 846d29c14d0d7d26 act []
>   ifindex 2 name handle_egress flags direct-action flags_gen [not_in_hw ]
>             prog_id 3193 tag 387d281be9fe77aa
>   ]