netdev - Re: [PATCH net-next 0/9] net: Kernel side filtering for route dumps

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:   Thu, 11 Oct 2018 12:07:24 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Sowmini Varadhan <sowmini.varadhan@...cle.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Cc:     David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
        davem@...emloft.net, David Ahern <dsahern@...il.com>
Subject: Re: [PATCH net-next 0/9] net: Kernel side filtering for route dumps

On 2018-10-11 11:46 a.m., Sowmini Varadhan wrote:
> On (10/11/18 08:26), Stephen Hemminger wrote:
>> You can do the something like this already with BPF socket filters.
>> But writing BPF for multi-part messages is hard.
> 
> Indeed. And I was just experimenting with this for ARP just last week.
> So to handle the caes of "ip neigh show a.b.c.d" without walking through
> the entire arp table and filtering in userspace, you could add a sk_filter()
> hook like this:
> 

If this could be done a lot earlier aka at xxx_fill_info() bpf would
be a very good answer.
skb->sk (hence attached filter) should be available at that point.
Classical bpf per Sowmini's example maybe trickier.
Better - why dont we have an ebpf hook at this stage and then
we dont have to make changes to the kernel when someone adds
one more field to the filter?

BTW: useful for events as well - not just dumps (as the name
fib_dump_filter suggests)

cheers,
jamal