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
| ||
|
Date: Mon, 18 Jul 2016 06:08:22 -0400 From: Jamal Hadi Salim <jhs@...atatu.com> To: Daniel Borkmann <daniel@...earbox.net>, Alexei Starovoitov <alexei.starovoitov@...il.com> Cc: davem@...emloft.net, netdev@...r.kernel.org, xiyou.wangcong@...il.com, nikolay@...ulusnetworks.com Subject: Re: [PATCH net-next 1/1] net_sched: Introduce skbmod action On 16-07-18 05:44 AM, Daniel Borkmann wrote: > On 07/18/2016 08:51 AM, Jamal Hadi Salim wrote: >> On 16-07-18 12:19 AM, Alexei Starovoitov wrote: > Looking at that just out of curiosity on how complex it could look > for src/dst mac, is it actually functional in iproute2 upstream tree? > No it is a bunch of bash script wrapping we did on top of pedit (which should be no different than adding it to m_pedit as an extension). We started there then decided that this feature is mostly used with mirred all the time - so modified mirred. > All I see is that pedit can look up 3rd party modules via get_pedit_kind(), > so it will pick p_%s.so, if built as such, and there's code for p_ip, > p_tcp, p_udp, p_icmp. But then, for example, all I see in p_udp.c is > since initial iproute2 import in 2005, apart from some cleanups by > Stephen: > Yes, IP and tcp should be fine. Others were place holders. Note, there is even no need to change pedit - you could write a bash script as we did. > static int > parse_udp(int *argc_p, char ***argv_p, struct tc_pedit_sel *sel, struct > tc_pedit_key *tkey) > { > int res = -1; > return res; > } > > struct m_pedit_util p_pedit_udp = { > NULL, > "udp", > parse_udp, > }; > > Same for tcp, icmp, ipv6 bits code ... :/ Is it still planned to eventually > complete these? someone else could run with it; at the moment i think this was ok at small scale but it hasnt worked well in a larger scale. When you write other apps (other than tc) to use these APIs parsing all the 32 bit chunks is more cumbersome then getting a struct which gives me precise info. I agree that from a usability PoV, it might be nice to > have some kind of 'pretty printer' for it besides the existing config > parser there (e.g. when we know that a loaded instance was done with a > high-level module, we could annotate that for retrieval on dump or such). > If i could tag the structure with something the kernel then returns to me when i dump, I could add nice pretty printers (same arguement applies to u32). But that doesnt solve the programmability issue as being a good cause. cheers, jamal
Powered by blists - more mailing lists