Re: New Firewall (hpf) for DragonFlyBSD

["Proceau" <news@xxxxxxxxxxxxxxxx>]

"Sebastien Petit" <spe@xxxxxxxxxxxxxxxx> a écrit dans le message de
news:3fff0e4c$0$181$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > On Friday 09 January 2004 18:06, Simon 'corecode' Schubert wrote:
> > > On 09.01.2004, at 15:28, Seb wrote:
> > > > Here you can found patch for using High Performance Firewall under
> > > > DragonFlyBSD. This firewall is a new type and exprimental. It's a
> > > > constant
> > > > time firewall, so CPU consumption is not dependent of rules number.
> > > > This a
> > > > turboACL like implementation so the kernel code is very very little.
> > > > Actually, hpf recognize some ipfw syntax but an ipfilter parser can
be
> > > > developped. Dynamic rules are not supported for the moment and some
> > > > options
> > > > too. You can see at http://www.phear.org/~spe/syntaxe.txt what type
of
> > > > syntax is recognized.
> > >
> > > I'm sorry, maybe I'm just ignorant, but doesn't such a tree need
256^14
> > > (or 13) entries?
> > >
>
> No, the tree represents your rules and is optimized, multiple nodes can
link
> on only one another node. btw, you can have (with no optimization)
14KBytes
> per rule on IA32 maximum. In reality, with optimization tree, the average
> size per rule is less than 14 Bytes.
>
> > > Also, using ints to store pointers won't work on all architectures.
>
> This code is i386 oriented but can be changed for storing pointers with 8
> bytes or more. This is an experimental code, not a definitve one. I try to
> see how I can update it for working under 64 bits architectures. What's
the
> architecture concerned by the problem of int for storing pointers ?
>
> >
> > Yapp - apart from being highly unreadable - your code is _really_ i386
> centric
> > and does not care about storage sizes or byte order at all. Furthermore
> it's
> > ignorant on real life things like incomplete/short mbufs, encapsulation
> etc.
> > pp.
>
> Unreadable is a big word. This is just a traverses tree. I try to see if
> there is a problem with byte order (htons(), ntohs()).
> btw, I work on hpf actually for deleting problems about incomplete/short
> mbufs and encapsulation.
>
> >
> > I am really curious how you plan to support IPv6, btw ;)
> >
>
> Ipv6 is not difficult, it's just another tree adapted to this protocol,
with
> a 128 bytes deep for ip src/dst. But I don't support IPv6 for the moment,
> it's just for IPv4 on first revisions.
>
> > Nonetheless, it's an interesting approach for very special purpose, but
> not
> > (yet) fit for real-life applications IMO.
>
> You're right, it'as an experimental code, not a definitive one for
> production servers. Try to see this code as proof of concept, bug can be
> corrected for other architecture than IA32 rapidly. I work actually for
> correcting these problems.
> Thank you for your help.
>
> Regards,
> Sebastien.
> --
> spe@xxxxxxxxxxxxxxxx
>

Hi,



 For support the whole of the sizes to point, a solution would be to use an
offset for architectures other than 32 bits. The structures of table are
allocated in once and it places in a memory capacity of less 4giga, the
solution for example with architectures 64bits would be to consider that
address memory at the time of the changes of table in table is the whole
value 32bits + a base of the size of the pointers (64bits), that amounts
manufacturing pages.



With this solution some is the size of the pointers, the table remains
tables of integer, and the relocation is a simple addition thus a fast
instruction (1cycle).



For the implementation, I would make in made an end of code managing with
relocation for any architecture other than 32bits.



For the bigedian and littleedian, your kernel code no affection, because you
read octet by octet.



Proceau.