On 07/15/2015 10:04 PM, Daniel Borkmann wrote:
On 07/15/2015 07:50 PM, Pablo Neira Ayuso wrote:
On Sat, Jul 11, 2015 at 03:14:07AM +0200, Daniel Borkmann wrote:
This work adds the possibility of deriving the zone id from the skb->mark
field in a scalable manner. This allows for having only a single template
serving 100s .. 1000s of different zones, for example, instead of needing
to have one match for each zone as an extra CT jump target. Note that we'd
need to have this information attached to the template as at the time when
we're trying to lookup a possible ct object, we already need to know zone
information for a possible match when going into __nf_conntrack_find_get().
This work provides a minimal implementation for a possible mapping.
I think connmark is a better place for this feature, given that the
zone is a ct extension. Moreover, I guess it will not take long until
someone sends us a patch to perform some bitwise operation to only
fetch some of the skb->mark bits into the zone.
Hm, we do need the zoning information *before* we do the actual lookup for
a ct object (non-template I mean), otherwise we don't know in which zone to
find it. When I looked into this, the connmark target is applied afterwards
on the actual ct object.
So you mean to add this to the raw table, so that someone could for each skb
assign ct->mark := skb->mark on the template and then have zone := ct->mark,
so we can use it for looking up? I would also need more than a single template
for that, right, as otherwise if I'd have arbitrary ct->mark := skb->mark
assignments in parallel, then we'd race. The current seems rather simple.
Sorry to bug you again on this patchset. I've been thinking a bit more
about your suggestion, my previous thoughts/reply on this, and how to move
forward. Lets presume for a moment, we would indeed place this into the
connmark target.
That would mean, we want to store the mark from the skb first into ct->mark
and then into the zone of the ct. We would need to do this on the template
itself, so that when the packet comes in, we know in which zone we're going
to do the actual lookup of a ct entry. When using a single, global template,
this seems racy, you would at least need to make sure that during the lookup
it's not being overwritten by other incoming skbs. If you say, the ct->mark
assignment should be skipped and the skb->mark should directly be assigned
to the zone, then why putting this into connmark as it has nothing to do with
the connection mark anymore (it would also avoid further unnecessary dependency
of NF_CONNTRACK_ZONES on NF_CONNTRACK_MARK and NETFILTER_XT_CONNMARK). But
also here, we'd have the same race issues as mentioned with ct->mark when
overwriting zone ids. The only thing I could imagine would be for the template
to hold a possible mask in the ct->mark itself, which could be user configured,
and then does in pseudocode, tmpl_zone->id := skb->mark & tmpl->mark. If
someone would really have such a use case (?), fair enough, this could be
followed-up.
The current approach implemented here that I found so far most appealing
and having the least complexity, was to just have a /single/ template and to
overwrite the zone->id with skb->mark on the ptr we have sitting on the stack.
It avoids all the issues mentioned. But perhaps you mean something entirely
different and I just seem to misinterpret your answer, hmm.
Thanks again, Pablo.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
