From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Josefsson Subject: Re: [PATCH 1/2] string match for iptables Date: Thu, 25 Aug 2005 18:54:19 +0200 Message-ID: <1124988859.28166.28.camel@localhost.localdomain> References: <43075517.3070405@eurodev.net> <43075BEA.1030701@trash.net> <20050820.131403.37427784.davem@davemloft.net> <20050825104258.GU4442@rama.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-67zdlgeN6ZkM+ZGIXju/" Cc: netfilter-devel@lists.netfilter.org, pablo@eurodev.net, kaber@trash.net Return-path: To: Harald Welte In-Reply-To: <20050825104258.GU4442@rama.de.gnumonks.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org --=-67zdlgeN6ZkM+ZGIXju/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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) >=20 > 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. >=20 > 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? --=20 /Martin --=-67zdlgeN6ZkM+ZGIXju/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDDfe7Wm2vlfa207ERApTpAKCkPpBMKC5fjY/QjevyIsMuI06PcACguKcP ZhRvjF2v8EITp82ZRqe6Hyw= =Qb2D -----END PGP SIGNATURE----- --=-67zdlgeN6ZkM+ZGIXju/--