pf kernel module(s)

Yar Tikhiy yar at comp.chem.msu.su
Sun Oct 2 13:04:19 PDT 2005


On Sun, Oct 02, 2005 at 08:51:57PM +0200, Max Laier wrote:
> 
> 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.

OK, this issue seems to need revisiting later.

> 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).

Just looked at the pf kernel code and saw the following:
- DEV_PFLOG is transormed into NPFLOG because OpenBSD still uses
  old config(8) semantics;
- with __FreeBSD__ defined, NPFLOG is used only in if_pflog.h to
  define PFLOG_PACKET() as the actual log function call, or a nul
  statement.

Can't we call the log function by a pointer to it, which could be
NULL to indicate no logging support loaded?  The pflog0 interface
itself can be created at any time since we are lucky to have fully
dynamic network interfaces in our kernel.

My concern is that with no MODULES_WITH_WORLD chads around, i.e.,
when modules' Makefiles no longer create magic opt_*.h with needed
options, it will be rather problematic to compile in pflog support
conditionally, and pf.ko will be broken.

> 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.

Thanks a lot for your detailed considerations!  I think they will
be of value to the developer who decides to improve the area, be
it me or someone else :-)

-- 
Yar


More information about the freebsd-pf mailing list