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
| ||
|
Message-ID: <CAM0EoM=D5YmMTrmNORcVCbAMVFcq=id_v+FSv-UqR1rT2B0xjg@mail.gmail.com> Date: Sun, 2 Oct 2022 09:59:37 -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 2:19 PM Nikolay Aleksandrov <razor@...ckwall.org> wrote: > > On 30/09/2022 19:36, Jamal Hadi Salim wrote: > > On Fri, Sep 30, 2022 at 10:34 AM Nikolay Aleksandrov > > <razor@...ckwall.org> wrote: [..] > > You only have one object type though per netlink request i.e you > > dont have in the same message fdb and mdb objects? > > > > Yep, it is object-type and family- specific, as is the call itself. > Ok, so that makes it easier. [..] > > Isnt it sufficient to indicate what objects need to be deleted based on presence > > of TLVs or the service header for that object? > > > > That was my initial proposal for the fdbs. :) When flush attribute was present it would > act on it (and filter based on embedded filters). The only non-intuitive part was that it > happened through SETLINK (changelink), which is a bit strange for a delete op. > > >>> 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. > > > > Personally, I prefer the complete netlink approach (tlvs describing the operation and filters). > In the end the flag was close enough, I kept all of the family specific code the same just the entry > point was different and other families could use it as a modifier to their del commands. > BTW, it seems that nftables is an outlier. You should still be able to use NLM_F_ROOT acronmy for DELETE. act_api uses NLM_F_ROOT on delete to flush the whole table of actions. My git-archealogy-foo says since 2005. NLM_F_NONREC was added in 2017. So you really should just be able to use NLM_F_ROOT to check for Delete of the whole table and TLV specific to service to filter further. > >> > >> 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? > > My first approach, which wasn't using bpf, used the tlv type to define specific filters on the various > types, incl. binary (which at the time was only an exact match, could be improved though). BPF w/ btf > would be the obvious choice these days. > The filter TLVs are good because the rest of the world can use them. The challenge is experessability. Like you say above, exact match is easy; inet diag has its own DSL to describe things which could be easily extended. A solution like a Lua script is second best and of course not to rule out ebpf - but that requires more skills. > > 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 > > Yeah, I remember CL having scaling issues in some user-space software that was snooping > netlink messages and that's the reason I looked into filtering at that time. > They are related problems. When you have 1000s of potential events it just doesnt scale. My idea was to specify a filter to select a subset and then open multiple sockets each specifying a different filter subset. cheers, jamal
Powered by blists - more mailing lists