netdev - Re: [PATCH RFC] ipv6: fix route selection if kernel is not compiled with CONFIG_IPV6_ROUTER

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130712192023.GP12611@order.stressinduktion.org>
Date:	Fri, 12 Jul 2013 21:20:23 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:	netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org,
	petrus.lt@...il.com, davem@...emloft.net
Subject: Re: [PATCH RFC] ipv6: fix route selection if kernel is not compiled with CONFIG_IPV6_ROUTER_PREF

On Fri, Jul 12, 2013 at 09:01:17PM +0200, Nicolas Dichtel wrote:
> Le 12/07/2013 18:19, Hannes Frederic Sowa a écrit :
> >On Fri, Jul 12, 2013 at 02:04:45PM +0200, Nicolas Dichtel wrote:
> >>It's possible to add a glue to check this counter when we play with these
> >>flags, but it's ugly.
> >>
> >>Maybe the check against RTF_EXPIRES is fundamentally wrong. Checking
> >>RTF_ADDRCONF|RTF_DYNAMIC should be enough, what do you think?
> >
> >Yes, this seems to be the best option now. I will audit the source if
> >RTF_ADDRCONF and RTF_DYNAMIC are immutable after dst construction and
> >if other errors could arise for that and would go with this solution then.
> >
> >What do you think about making ecmp routes explicit by adding RTF_ECMP
> >flag?
> Why not, but you will have to be careful on insertion and deletion. Next 
> hop can be added one by one and deleted one by one.

Ok, we can have a look to do so in -next.

> >
> >>In another hand, we can discuss about the initial assumption, that was
> >>"only static routes are part of ECMP routes". I'm thinking of what are the
> >>consequence if we accept to accept all routes, without checking any flags.
> >
> >I don't have a good feeling about that. But I may be wrong.
> Same for me, but for now, I don't have any argument ;-) The above solution 
> is probably the better way for now.

To go without RTF_EXPIRES seems the way to go. I still am unsure if we need to
propagate the RTF_DYNAMIC flag in case we update the expiration date on a
route.

--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -682,6 +682,7 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct rt6_info *rt,
                                        rt->rt6i_nsiblings = 0;
                                if (!(iter->rt6i_flags & RTF_EXPIRES))
                                        return -EEXIST;
+                               iter->rt6i_flags |= rt->rt6i_flags & RTF_DYNAMIC;
                                if (!(rt->rt6i_flags & RTF_EXPIRES))
                                        rt6_clean_expires(iter);
                                else

I hope to have identified all possible site-effects later today.

Thanks,

  Hannes

--
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