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