From owner-freebsd-current Sat Dec 21 20:44: 6 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 9BA2137B401 for ; Sat, 21 Dec 2002 20:44:03 -0800 (PST) Received: from mta02ps.bigpond.com (mta02ps.bigpond.com [144.135.25.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 879B043EDC for ; Sat, 21 Dec 2002 20:44:02 -0800 (PST) (envelope-from darrenr@reed.wattle.id.au) Received: from CPE-61-9-164-106.vic.bigpond.net.au ([144.135.25.69]) by mta02ps.bigpond.com (Netscape Messaging Server 4.15 mta02ps Jul 16 2002 22:47:55) with SMTP id H7I7TC00.ABE for ; Sun, 22 Dec 2002 14:44:00 +1000 Received: from CPE-203-51-160-253.vic.bigpond.net.au ([203.51.160.253]) by PSMAM01.mailsvc.email.bigpond.com(MailRouter V3.0n 71/13625915); 22 Dec 2002 14:43:59 Received: (from root@localhost) by CPE-61-9-164-106.vic.bigpond.net.au (8.11.0/8.11.0) id gBM4hVr24179; Sun, 22 Dec 2002 15:43:31 +1100 From: Darren Reed Message-Id: <200212220443.PAA21632@avalon.reed.wattle.id.au> Subject: Re: PFIL_HOOKS should be made default in 5.0 In-Reply-To: <3E04AECF.F7D62C7C@mindspring.com> To: Terry Lambert Date: Sun, 22 Dec 2002 15:43:14 +1100 Cc: Darren Reed , Sergey Mokryshev , Vallo Kallaste , Sam Leffler , Hiten Pandya , current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 In some email I received from Terry Lambert, sie wrote: [...] > The original posting in this thread gave a patch to unconditionalize > the PFIL_HOOKS thing, so that the ipfilter module could load on a > default kernel, without having to do a reasonable amount of work. ipfilter being the only code that currently uses that mechanism. At least I think it's a better approach than using the LKM hooks present in FreeBSD prior to 5.x > 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. > 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. > the complaint was because they wanted it > to be resolved in a particular way, so that they got a result that > they weren't willing to ask for directly. Solving the first one > left them unhappy. > 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. > > The purpose of pfil(9) is not to facilitate ipfilter but to act > > as a mechanism for anything to filter packets to use it as the > > way to receive packets. Ideally ipfw* should also use pfil(9) > > and not have those large chunks of code in ip_{in,out}put.c. > > 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 :-) :) Well, for BPF it works. Lots of devices have bpf_*tap()s in them and nobody bothers about the overhead from that. 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. > > > Probably the correct thing to do is to wire in ipfilter as a > > > Netgraph module. > > > > If/when the joining between layer 2 and layer 3 in the kernel > > uses netgraph rather than the current mechanisms, then it would > > be appropriate to use netgraph for ipfilter. > > That's not a good demand; here's why: There are two types of > data paths: (1) the fast path, and (2) the path for research and > for things that are going to be slow anyway, by their nature. 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. > 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". 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. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message