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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 27 Jul 2012 16:00:01 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: fix TCP early demux

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Fri, 27 Jul 2012 23:34:33 +0200

> I wonder why cookie is not stored in dst, and must be stored outside
> of it ?

Because in ipv6, cloned routes are never invalidated on a route
insertion or deletion.  We keep them around.

The fn_sernum tracks path reachability, rather than validation of
dsts.

So when we delete or insert a new ipv6 route, we update the serial
number of all the FIB nodes on the way down to the insert/delete
point.

If, afterwards, we can still reach a route cloned from one of those
entries successfully.  It is still valid.

If we were to store the serial number on the dst, it would invalidate
the cloned route, which the ipv6 code is largely not designed for.

To be honest, the whole route validation scheme in ipv6 was
jackhammered into place.  It was basically two years of Alexey
repairing the largely broken scheme that Pedro had put into place.

This is ~1997 legacy stuff.

It deserves a complete rewrite, but we are too busy with ipv4 at the
moment.  And frankly if nobody other than myself was concerned enough
to delete the ipv4 routing cache (code people actually use) the
likelyhood of anyone embarking on a task of similar size for ipv6 is
basically zero.
--
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

Powered by blists - more mailing lists