Date: Sun, 22 Dec 2002 15:43:14 +1100 From: Darren Reed <darrenr@reed.wattle.id.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: Darren Reed <darrenr@reed.wattle.id.au>, Sergey Mokryshev <mokr@mokr.net>, Vallo Kallaste <kalts@estpak.ee>, Sam Leffler <sam@errno.com>, Hiten Pandya <hiten@unixdaemons.com>, current@FreeBSD.ORG Subject: Re: PFIL_HOOKS should be made default in 5.0 Message-ID: <200212220443.PAA21632@avalon.reed.wattle.id.au> In-Reply-To: <3E04AECF.F7D62C7C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212220443.PAA21632>