From owner-freebsd-current Sun Dec 22 10:23: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AF6637B405 for ; Sun, 22 Dec 2002 10:23:04 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9AAA43EE6 for ; Sun, 22 Dec 2002 10:23:03 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from [216.20.231.174] (helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18QAkT-0000Wh-00; Sun, 22 Dec 2002 10:22:49 -0800 Message-ID: <3E060298.70D2CA16@mindspring.com> Date: Sun, 22 Dec 2002 10:21:12 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Darren Reed Cc: Sergey Mokryshev , Vallo Kallaste , Sam Leffler , Hiten Pandya , current@FreeBSD.ORG Subject: Re: PFIL_HOOKS should be made default in 5.0 References: <200212220443.PAA21632@avalon.reed.wattle.id.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f33ea3f1d6c6f3221ae605c3a5feb727350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Darren Reed wrote: > > My response to that was that you could create accessor/mutator > > functions which were always defined, but not always functional. > > By using these functions, instead of trying to access the pointers > > directly, there are no undefined symbols, and you get the specific > > error message, rather than the generic: any message you want it to > > print. > > That doesn't work when ipfilter is compiled outside of the kernel > build directory (as often happens), where it is going to be unaware > of whether or not PFIL_HOOKS has been defined for the kernel. Yes, it does work... to get the specific, rather than the general error message. What *doesn't* work is the module fails to register when the hooks aren't present. The original complaint was against the error message not being right, but what the complainer *really* wanted was to be able to load an ipfilter module into a GENERIC kernel. They were being disingenuous: they misrepresented their solution as being the only solution to the error message "problem" (a strawman), when what they really wanted was ipfilter support by default in GENERIC. I don't have a problem with people wanting that, but they should not misrepresent the request as if they were asking for something else ("Fix confusing error message for users"). Whether or not people would accept the slowdown, knowing the real reason behind the proposed change, is something else entirely. I think you touch on an important point here: kernel options that have to be known to modules at the time that the modules are compiled. PHK and other have touched on this as well, in the discussion about making the kernel structures stay the same size, no matter what options are being used to compile the kernel; that *part* of the fix. I think the real fix is to get rid of compile time options. But that can't be done for options that have a lot of overhead, whose pay-off is to add functionality that most people will never use. > > The real reason is that the > > people complaining don't want to have to recompile the kernel to > > use the ipfilter module: > > That or any other module that uses the pfil(9) interface. Sure. And they should have come out and said that, instead of pretending they were trying to de-obfuscate an error message. I think that, until the pfil(9) interface uses an existing hook, like the netgraph one, or until netgraph is rewriten to use the pfil(9) interface instead of having its own hooks, that adding yet-more-hooks -- and overhead -- to the packet processing path is a bad thing to have turned on by default. > > But compiling the kernel with the hooks in place is not the only > > way to solve the problem. > > It is a better step forward than the proposal I've seen you put > forward about accessor hooks and having them prevent the obscure > modload error message. It's a better step forward *for ipfilter*. Who else uses pfil(9)? My proposal was an equally valid means of being able to trap the fact that the kernel wasn't compiled with PFIL_HOOKS, without giving an obscure "undefined symbol" error. If the problem as stated were what was really being addressed, my solution would have been much better: it doesn't add overhead to the fast-path in the common case. 8-). > > Yeah, that's the reason that BPF and netgraph and streams and ... > > were invented, too. Wouldn't it be great if everyone adopted the > > API I like best? 8-) 8-). > > Terry, did you have any hand in writing netgraph ? I've seen hardly > anyone else put their hand up in favour of it so I'm suspecting a > certain amount of bias here :-) :) No, that's Julian's baby. I talked to him about it when it was happening, and with Archie on the tty node, and various other people, as they've written modules for it. My bias, if any, though, is actually against multiple packet processing path hook interfaces. I'd be just as happy to have pfil(9) be the only interface... if someone were to rewrite the netgraph, BPF, and other code to use pfil(9). > Well, for BPF it works. Lots of devices have bpf_*tap()s in them > and nobody bothers about the overhead from that. I do... 8-) 8-). > For STREAMS you don't need to do anything. > > I suppose I'm trying to push pfil(9) into the same kind of role as > BPF. Yep. And I'm saying "Dere can be only one!". 8-). > Well, let me describe how ipfilter works in a STREAMS environment, > or rather, how version 4.0 of ipfilter works. > > To separate the STREAMS gunk out of ipfilter (or as much as possible) > I wrote an equivalent of pfil(9) for HP-UX 11/Solaris. That is a > STREAMS module that gets push'd onto the network device before the > IP module does so all IP traffic goes through pfil(9). IPFilter > registers with pfil(9) to intercept the packets that would otherwise > be going straight through it to the IP routines. > > For it to be worthwhile to use netgraph on FreeBSD, FreeBSD would need > to be re-engineered such that the linkage between layer 2 devices (all > of the ethernet cards, etc) and layer 3 code (ip, ipv6, etc) was done > through netgraph - or at least that's how I see it. From a security > perspective that's definately how I'd want it to be - the filtering > as the middle man, not some inspector hanging off the side somewhere. You can ask Julian; I think this can be forced, using interface nodes (from my understanding of the code)... > > The ipfilter code is in the second category. > > > > It's really bogus to insist that everything take the slow path > > because something slow has to take the slow path. > > I think you're missing the point about why people want "everything" to > take the "slow path". People are using it for security and when you're > doing that, there is no "fast path" or "slow path", there is only a > "secure path". I typically do that only when I'm using FreeBSD as my firewall; I'm more likely to use PIX or something else for that role (that's a personal preferance thing). Once you are behind the firewall, the machines that are there aren't really doing dual-duty as a firewall *and* a web server. So one box out of a *lot* of boxes needs what you describe. After that, we're back to "fast path". > btw, I did make an effort to read how to use netgraph and I'm shocked. > It looks like even more effort to use than STREAMS and not in a good > way either. IMO, it's a lot of work to use. But it doesn't have the in vs. out pipeline stalls that you end up with STREAMS (where you have to have two run cycles to get a packet in and back), and it's a lot more flexible, generally (FWIW). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message