> Excuse me, but could anyone tell me what BPF and firewalling do have in
> common?

nothing right now.

> It was my understanding (verified by just looking into the latest version
> of some ethernet driver) that BPF only allows you to spy at packets from
> user level programs which might reduce the number of packets by specifying
> a filter. There is no way (I can see) that allows you by use of BPF to
> request that the kernel drop a packet.
> 
> Am I totally out here?

No, you're right on.


The question which Charles raised (and which i would have raised, if i
had time; it was why i requested more information on the operation of
the filter) is a valid one.

Given that you already have general packet filtering machinery in the
kernel, and that that filtering machinery already has a "selection
mechanism", why invent and use a whole _new_ set of filtering
machinery to determine whether or not packets are passed through?


If you _do_ have two sets of filtering machinery, then you've got an
interposition problem: where's the appropriate place to interpose the
"block the packets" filter?  I can see reasons why you'd want it on
either side of the BPF-ish "filter", namely:
	(1) you'd like some applications to get only things that
		haven't been blocked
	(2) you'd like other applications (e.g. security monitors) to
		receive all, or at least a certain subset of, the
		packets that _have_ been blocked.

Given that BPF already has the machinery in place to handle things
like passing packets out to user-land, i'd say there would be three
things to do, to make it a real filter:
	(1) allow "outside the packet filter" to be specified for
		the packet "sniffers."  default to "inside the filter,"
		so old "sniffers" will continue to work.
	(2) make the return value from the bpf input call in the net
		drivers a boolean, and make it control whether the
		packet is passed on.
	(3) add a "master bpf control" device, in addition to
		/dev/bpf{0,1,...}, which would handle setting the
		master input filter.		


The master input filter's result would, rather than causing the packet
to be passed out through a 'bpf' device, cause the packet to be be
passed on/dropped.

I figure, put the master on a different device number, and supply
slightly different open/close/etc glue routines for it than the
others, because it serves a different purpose and behaves in a
different way.

Looking at the BPF code, it shouldn't be hard to implement a filter in
this way.  In particular, bpf_filter is already an independent
function, etc., so it's just a matter of using it correctly.


cgd