pf kernel module(s)
Max Laier
max at love2party.net
Sun Oct 2 11:52:25 PDT 2005
Yar,
On Sunday 02 October 2005 17:16, Yar Tikhiy wrote:
> While making an rc.d script for pfsync as I had promised here, I
> noticed that pf.ko didn't include support for pfsync. Closer study
> revealed that it would be better to split pf.ko in separate modules
> for pf itself, pflog, and pfsync. The reason is as follows.
>
> As MODULES_WITH_WORLD are about to depart for /dev/null soon, modules
> should not rely on the opt_*.h files they create with their Makefiles
> now: The configuration is to be obtained from the opt_*.h files in
> the kernel build directory. Therefore it will not be possible to
> include pflog or pfsync functionality in pf.ko unless it is in the
> main kernel file, too, which is ridiculous. OTOH, having separate
> pflog.ko and pfsync.ko would allow for the modules to be built
> irrespective of the current kernel configuration.
>
> If the separation is not possible now, the pf.ko module should
> include all the functionality irrespective of the DEV_PF, DEV_PFLOG,
> or DEV_PFSYNC values found in opt_pf.h. As a matter of fact, a
> modern FreeBSD device driver should rarely use DEV_FOO values in
> its code because the inclusion of the driver source files in the
> build process is the major sign of the driver being enabled, and
> device instances should be created dynamically. Alas, OpenBSD
> code doesn't seem to follow this trend, so I'd consider setting
> NPFLOG and NPFSYNC to 1 statically if possible.
There is one big issue with PFSYNC as a module. pfsync needs to register a
kernel level multicast protocol. This is not (yet) possible at runtime, but
needs to happen statically. So in order to use pfsync you need a pfsync
enabled kernel - and can just build in pfsync alltogether. All this makes a
pfsync.ko pretty useless.
The story for pflog is simply me reasoning that people don't usually want a
firewall without logging. And if we know whether or not we have to log at
compile time we can save (at least) one pointer deref per packet (and a lot
of hook-in/hook-out logic as well).
I am open to any improvement of the situation, just wanted to get out the
reasoning so you don't have to find out the hard way.
--
/"\ Best regards, | mlaier at freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier at EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20051002/cf234617/attachment.bin
More information about the freebsd-pf
mailing list