netdev - inetpeer in fib tables...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <20120607.151219.870388144120010595.davem@davemloft.net>
Date:	Thu, 07 Jun 2012 15:12:19 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	netdev@...r.kernel.org
Subject: inetpeer in fib tables...

Just a heads up on what I'm doing to fix the bug Stephen Hemminger
forwarded.

Essentially I'm going to put inetpeer roots into the FIB tables.
Since each FIB table is essentially a realm of destinations, this will
fix all of the problems like the one in the bugzilla report.

We still need Gao's per-ns inetpeer root patches because there are
situations where we don't have a FIB table context by which to select
an inetpeer root, so we need a global inetpeer tree to fallback onto.

Several kinds of routing lookups do not use a FIB lookup.  Also,
another case is the inetpeer lookup done for IPv4 fragmentation ID
wraparound avoidance.

Much of my changes have to do with handling the fact that we often
need to do the inetpeer lookup long after the route lookup.  And we
don't want to waste a whole pointer just to store the inetpeer root.

So I change the rt->peer to be rt->_peer and of type unsigned long.
Then we encode the pointer with the low bit signifying that the
value is actually a pointer to an inetpeer base.  Similar changes are
made for ipv6.

And similar handling is needed for TCP timewait sockets, to propagate
the inetpeer root to use for lookups or the fully resolved inetpeer.

The next problem is inetpeer tree invalidation.  Now that we'll have
multiple trees per address family, we can't just flush all inetpeers
for a given address family so easily as we can now.  The way this will
be handled is to give each peer a sequence number, and there is a
per-AF sequence number which will be bumped by the current
invalidation code.  Lookups check the sequence number of the inetpeer
root they are using and flush if necessary.

Anyways, once Gao properly respins his patches I'll merge net into
net-next and start submitting the inetpeer FIB table changes.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html