Date: Sun, 22 Dec 2002 10:21:12 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Darren Reed <darrenr@reed.wattle.id.au> Cc: 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: <3E060298.70D2CA16@mindspring.com> References: <200212220443.PAA21632@avalon.reed.wattle.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E060298.70D2CA16>