Date: Tue, 19 May 1998 21:19:17 +0200 From: Eivind Eklund <eivind@yes.no> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: kjc@csl.sony.co.jp, net@FreeBSD.ORG Subject: Re: struct ifnet handling... Message-ID: <19980519211917.64952@follo.net> In-Reply-To: <199805191523.RAA09734@labinfo.iet.unipi.it>; from Luigi Rizzo on Tue, May 19, 1998 at 05:23:37PM %2B0200 References: <19980519185349.49553@follo.net> <199805191523.RAA09734@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Moved to -net as commented prevsiously.
On Tue, May 19, 1998 at 05:23:37PM +0200, Luigi Rizzo wrote:
> > I'm referring to the implementation of the recv, xmit and 'via' rules.
> > They're implemented by running the _entire_ ruleset once when the
> > packet arrive, and once when it leave.
>
> oh, yes; but in this case, different rules might match the packet
> on the way in and out,
Sure. This is a result of the initial implementation not being
chains-oriented. There are a lot of rules that we're certain
shouldn't be used both on the way in and out - but they still are
checked everywhere.
We really should have at least the following chains:
iichain - Interface specific Input Chain
lichain - Locally generated input packet chain (not used for packets
coming in through a hardware interface)
gichain - Generic input chain
gochain - Generic output chain
lochain - Local delivery packet chain (not used for packets going out
through an interface)
iochain - Interface specific Output Chain
There are one iichain and one oochain for each interface. Possibly
lichain and lochain can be just interface chains hanging off lo0 - I
don't know how local delivery vs routing is handled by the routing
code.
Example: A packet coming from ep0 and being routed to vx0 would go
(progn
(run-chain (sort-by-rulenum (iichain "ep0") gichain))
(route-packet)
(run-chain (sort-by-rulenum (iochain "vx0") gochain)))
A packet created by the a local process and finally routed through vx0
is run through
(progn
(run-chain (sort-by-rulenum li gichain))
(route-packet)
(run-chain (sort-by-rulenum (iochain "vx0") gochain)))
Do you catch my drift?
Separating rules into separate chains like this is fairly is given one
of two conditions: (1) The system for specifying rules is regular,
making manipulation easy, or (2) the original input of rules is
oriented towards the chains.
I think it if worthwhile to achive (1) no matter what; it will allow a
lot of flexibility and optimizations. (2) then would just make the
user-interface more efficient, and probably isn't that important. We
could have a 'default chain' that behave like the present system.
> and this is a lesser problem with properly
> implemented SKIPTO rules (i have them in the current dummynet code).
This is a problem you can work around if you know the backend, and
write front-end code optimized to avoid the problems with the backend.
Wrong solution - people using the frontend shouldn't have to know how
the backend code works (especially not since this is easy to
machine-optimize).
> you see, i have been beating this code for the last 10
> days or so when i integrated dummynet with the firewall code --
> see http://www.iet.unipi.it/~luigi/ip_dummynet/ if you have missed
> the announcement.
I've seen it. Neat work!
> I think the problem with our ipfw code is still in the way rules
> are defined. Probably they were designed not thinking too much to
> possible implementations, but just to be as generic as possible.
The problem is that _everything_ is assumed to be 'fixed' - ie,
everything is modelled without room for change. The rules are made as
if the present way of parsing them is the only; the userland/kernel
interface is based on passing entire rules over; etc.
> > One way is to look at a packet (including flags etc) as a series of
> > bits which can be masked against. This is fairly tractable - rules
>
> good idea implementation-wise: then each instruction becomes an
> offset, length, mask and match value.
Well, in practice you will want to have it as a set of different
bit-vectors, to not have to re-organize things. But it is a useful
teorethical construct which maps fairly well onto code.
> I only have a problem with JUMP rules: i am not sure if the old
> firewall code allowed backward jumps, but if you do then you must be
> careful to avoid loops... probably it is better to not allow backward
> jumps at all ?
Backwards jumps are not allowed at all at present, so that shouldn't
be a problem. The problem with jumps is that they represent a
difference for all rules that come after them if you are doing
optimization/normalization of rules - thus each split will (in many
cases) double to work for the rules after them. It isn't really
difficult to handle, it is just a severe slowdown for the
opimization-pass.
> > I have code to do some of these transforms available somewhere; if you
> > want to play with this to look at different optimization models, you
> > can have a copy.
>
> don't have the time now, maybe in a couple of weeks. Do you mean that
> you have some kind of rewriting code that takes current firewall
> specification and compiles in lower-level instructions ?
No. I have code to switch between different regular representations
of firewall rules; I haven't yet implemented a transform from the
FreeBSD firewall rules to a regular set.
I was planning to do that once I had the userland/kernel interface
sorted out.
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980519211917.64952>