netdev - Re: [PATCH net-next] docs: netlink: clarify the historical baggage of Netlink flags

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: <CAM0EoMn09qMjpHV5dHEaMDBCuRBVt6qbcTToXCeqCQ-+-7UJeQ@mail.gmail.com>
Date:   Fri, 30 Sep 2022 12:36:59 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Nikolay Aleksandrov <razor@...ckwall.org>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
        Johannes Berg <johannes@...solutions.net>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Florian Westphal <fw@...len.de>,
        Jacob Keller <jacob.e.keller@...el.com>,
        Florent Fourcot <florent.fourcot@...irst.fr>,
        Guillaume Nault <gnault@...hat.com>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>,
        Hangbin Liu <liuhangbin@...il.com>
Subject: Re: [PATCH net-next] docs: netlink: clarify the historical baggage of
 Netlink flags

On Fri, Sep 30, 2022 at 10:34 AM Nikolay Aleksandrov
<razor@...ckwall.org> wrote:
>
> On 30/09/2022 17:24, Jamal Hadi Salim wrote:
> > On Fri, Sep 30, 2022 at 7:29 AM Nikolay Aleksandrov <razor@...ckwall.org> wrote:

[..]

> >
> > I think what you are looking for is a way to either get or delete
> > selective objects
> > (dump and flush dont filter - they mean "everything"); iow, you send a filtering
>
> They must be able to flush everything, too. Filter matching all/empty filter, we need
> it for mdbs and possibly other object types would want that.

You only have one object type though per netlink request i.e you
dont have in the same message fdb and mdb objects?

> > expression and a get/del command alongside it. The filtering
> > expression is very specific
> > to the object and needs to be specified as such a TLV is appropriate.
> >
>
> Right, and that is what got implemented. The filtering TLVs are bridge and fdb-specific
> they don't affect any other subsystem. The BULK flag denotes the delete will
> affect multiple objects.
>

Isnt it sufficient to indicate what objects need to be deleted based on presence
of TLVs or the service header for that object?

> > Really NLM_F_ROOT and _MATCH are sufficient. The filtering expression is
> > the challenge.
>
> NLM_F_ROOT isn't usable for a DEL expression because its bit is already used by NLM_F_NONREC
> and it wouldn't be nice to change meaning of the bit based on the subsystem. NLM_F_MATCH's bit
> actually matches NLM_F_BULK :)
>

Ouch. Ok, it got messy over time i guess. We probably should have
spent more time
discussing NLM_F_NONREC since it has a single user with very specific
need and it
got imposed on all.
I get your point - i am still not sure if a global flag is the right answer.

>
> Sometime back I played with a different idea - expressing the filters with the existing TLV objects
> so whatever can be specified by user-space can also be used as a filter (also for filtering
> dump requests) with some introspection. The lua idea sounds nice though.

So what is the content of the TLV in that case?
I think ebpf may work with some acrobatics. We did try classical ebpf and it was
messy. Note for scaling, this is not just about Delete and Get but
also for generated
events, where one can send to the kernel a filter so they dont see a broadcast
of everything. See for example a use case here:
https://www.files.netdevconf.info/d/46fd7e152d1d4f6c88ac/files/?p=/LargeScaleTCPAnalytics.pdf

cheers,
jamal