netdev - Re: [PATCH] ipv6: clear RTF_EXPIRES when call ip6_rt

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: <20131218062000.GC27460@order.stressinduktion.org>
Date:	Wed, 18 Dec 2013 07:20:00 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	RongQing Li <roy.qing.li@...il.com>
Cc:	Gao feng <gaofeng@...fujitsu.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: clear RTF_EXPIRES when call ip6_rt_copy

On Wed, Dec 18, 2013 at 10:21:12AM +0800, RongQing Li wrote:
> On Wed, Dec 18, 2013 at 10:09 AM, Gao feng <gaofeng@...fujitsu.com> wrote:
> > On 12/18/2013 09:58 AM, RongQing Li wrote:
> >> On Wed, Dec 18, 2013 at 8:48 AM, Gao feng <gaofeng@...fujitsu.com> wrote:
> >>> On 12/17/2013 09:48 PM, Hannes Frederic Sowa wrote:
> >>>> On Tue, Dec 17, 2013 at 03:46:24PM +0800, Gao feng wrote:
> >>>>> The from of new cloned rt should not be set if it's impossible for the ort
> >>>>> to be expired.
> >>>>
> >>>> Actually, why do you think so? What could go wrong?
> >>>>
> >>>
> >>> I just don't want rt6_check_expired to check some impossible expired routes.
> >>>
> >>
> >> What is wrong if we set from for new cloned rt by checking if ort has
> >> RTF_EXPIRES flag?
> >
> >
> > The RTF_EXPIRES flag may be changed by router advertisment package,
> > the ort may become expired after you hadn't set from for new cloned rt.
> >
> > we should set from even this kind of ort doesn't have RTF_EXPIRES flag.
> 
> 
> Thanks;
> 
> Do we want to set from only from RA route?  if so,  we should check
> ort with RTF_ADDRCONF|RTF_DEFAULT, or RTF_ADDRCONF | RTF_ROUTEINFO,

Nope, as I said, also prefix routes which did get installed by hand locally
can have an expiration. I don't see any flag combination which ensure a
potential from does never expire. IMHO we should always from.

Also, in case we overwrite a route and the route is already in there, we reset
the expiry values: search for rt6_set_expires in fib6_add_rt2node.

We had the same problem with ECMP routes. We only wanted to add non-expiration
routes but we could not find a combination which did ensure that. In the end
we now also add non-expiration routes to an ecmp set (see commit
307f2fb95e9b96).

Greetings,

  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