In message <20020306195221.A1364@dhcp2.wlan.shagadelic.org>, Jason R Thorpe wri
tes:

>My solution to this was to implement a totally new filtering system,
>which had as fundamental design principles:
>
>	* Multiple filtering points, each with their own rulesets.
>

The ability to handle n>1 would be useful in a lot of contexts in the 
networking stack.  I'd love to have a separate routing table for IPsec 
to use.  For that matter, the distinction between bridging and routing 
tends to disappear if each interface could have its own routing tables 
and policies.  (By chance, just yesterday I was describing the System V 
Release 3 networking stack to someone.  While they got a lot of things 
wrong, the plumbing was a lot cleaner than Berkeley's.  Network devices 
aren't funny things, they live in /dev.  Most important, they're stream 
devices.  Conceptually (and pretty close to literally), what one did to 
configure the stack was to open /dev/ip, open each network device, and 
use various "plumbing" calls to attach the network devices to the 
bottom half of /dev/ip.  Then one attached /dev/ip to the bottom half 
of /dev/tcp, /dev/udp, etc.  The "streams" mechanisms provided the 
universal connectors.  The details are a lot more complex, and as I 
said they didn't get it all right by any means.  But it does solve a 
lot of problems in a very clean fashion.

> (I initially experimented
>	    with this idea by writing a simple BPF-to-C translator, and
>	    compiling the resulting C code.  The resulting rules ran extremely
>	    fast.  Obviously, through, you want to do the BPF-to-native
>	    translation in the kernel after allowing the kernel to verify
>	    the BPF program for safety.)

Now that's an interesting architectural challenge.  I suspect that you 
can't easily do that translation from the kernel (an upcall to gcc?), 
but the ability to download arbitrary machine code isn't that different 
than LKMs are now.  I wonder if there's a way to safely and efficiently
have kernel processes that share a bit of address space, but not all.

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com