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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 21 Nov 2007 01:25:54 +0100 From: Patrick McHardy <kaber@...sh.net> To: David Miller <davem@...emloft.net> CC: panther@...abit.hu, jengelh@...putergmbh.de, netdev@...r.kernel.org, netfilter-devel@...r.kernel.org Subject: Re: [PATCHv6 0/3] Interface group patches David Miller wrote: > From: Laszlo Attila Toth <panther@...abit.hu> > Date: Tue, 20 Nov 2007 14:52:12 +0100 > >> Jan Engelhardt írta: >>> On Nov 20 2007 14:14, Laszlo Attila Toth wrote: >>>> This is the 6th version of our interface group patches. >>>> >>>> The interface group value can be used to manage different interfaces >>>> at the same time such as in netfilter/iptables. >>> I take it you could not use...? >>> iptables -i iif1 -j dosomething >>> iptables -i iif2 -j dosomething >> This kind of usage requires static interface names. But there are >> dynamic interfaces such as ppp, where the actual name is not always >> known or sometimes they exist sometimes not. It is difficult to use >> iptables this way, and every ifup/ifdown requires change in the iptables >> ruleset (donwload it, modify and upload to the kernel). It may be too slow. > > This is actually not true these days. > > When network devices are created user events are generated and the > user can rename the device however they like using a mapping table of > any kind. > > And at such point the problem you present doesn't actually exist, you > can know what the device will be named. > > And if rule loading dynamically is slow, we should fix that instead of > creating infrastructure and interfaces we don't actually need. I actually like this feature. Matching on names in iptables has always been one of the major bottlenecks, taking (according to my last measurement, which is some time ago) about 1-2% of the total performance. This is of course in large parts because the interface match is present on *every* rule, but still some way to logically group interfaces seems useful to me, not only for iptables, but also for routing rules, traffic classifiers, af_packet sockets etc. I'm working on the incremental ruleset changing API BTW :) One of the changes will be that interface matching is not a default part of every rule, and without wildcards it will use the ifindex. But since the cost of this feature seems pretty low, I don't see a compelling reason against it. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists