Re: [PATCH 1/2] string match for iptables

[Martin Josefsson <gandalf@wlug.westbo.se>]

[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]

On Thu, 2005-08-25 at 18:54 +0200, Martin Josefsson wrote:

I wonder why davem got lost on the CC, he's there in my Sent folder but
not in the mail I got from netfilter-devel... I hope he makes it this
time.

> On Thu, 2005-08-25 at 12:42 +0200, Harald Welte wrote:
> 
> > > One thing that can help is to not put pointers into these rules,
> > > that is actually the most difficult case to handle.  Without
> > > pointers, the entire struct can be defined using portable types
> > > that require no translation.  Once you introduce a pointer, using
> > > the user's struct as-is becomes impossible.  (as an added bonus
> > > such rules could thus be sent over the wire as well, if we ever
> > > wanted to do that)
> > 
> > The only reason why a pointer is needed at all, is the "dump whole table
> > to userspace, do some modifications and read it back" approach.  I
> > seriously doubt that we would be able to change that assumption.  If we
> > did, it wouldn't be iptables anymore, but half-way into pkttables.
> > 
> > As an intermediate solution we could do some form of indirect
> > resolval/mapping.  The core could provide an allocation wrapper API
> > which matches/targets could use for malloc'ing their private data
> > structures.  In addition to a pointer, it would return an (32bit) ID.
> > That ID can then be embedded in kernel/userspace data structures.  When
> > userspace rules come in, the ID gets translated to the real pointer by
> > some call to that API of the core.
> 
> Now that we have support for diffrent revisions of matches/targets we
> can easily add new revisions that uses diffrent structs and later
> deprecate the older revisions.
> 
> Matches and targets have two sizes defined for their datastructures,
> size and userspacesize. size is the total size of the datastructure, the
> amount that is allocated for the rule private data. And userspacesize is
> the amount transferred to/from userspace when rules are modified.
> 
> So we could put all portable members at the top of the structure and all
> pointers at the end and set userspacesize to the offset of the first
> pointer in the structure. There's no need to transfer that data back and
> forth to userspace, it just introduces races in the cases where there's
> members used for refcounting in the structure.
> So the remaining problem is that the total size of the structure is
> diffrent on 32/64 bit.
> The userspacesize stays the same on both but not the part of the
> structure that holds the "kernelprivate data", iow the last part of the
> structure, that changes on 32/64bit and I don't think we can assume that
> the size on 64bit is 2 * size on 32bit, that only holds for non portable
> types, what if someone wants a portable size in this section...
> 
> Any ideas?
> 
-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]