netdev - Re: [PATCH net-next] ipv6: addrconf: fix mcast route for GRE devices

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

Message-ID: <1406744400.1908.20.camel@dcbw.local>
Date:	Wed, 30 Jul 2014 13:20:00 -0500
From:	Dan Williams <dcbw@...hat.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	David Lamparter <equinox@...c24.net>, netdev@...r.kernel.org,
	Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH net-next] ipv6: addrconf: fix mcast route for GRE devices

On Wed, 2014-07-30 at 20:03 +0200, Hannes Frederic Sowa wrote:
> On Wed, Jul 30, 2014, at 19:35, David Lamparter wrote:
> > On Wed, Jul 30, 2014 at 06:52:21PM +0200, Hannes Frederic Sowa wrote:
> > > On Mi, 2014-07-30 at 18:31 +0200, David Lamparter wrote:
> > > > On Wed, Jul 30, 2014 at 06:09:27PM +0200, Hannes Frederic Sowa wrote:
> > > > [cut]
> > > > > > On Wed, Jul 30, 2014 at 05:14:42PM +0200, Hannes Frederic Sowa wrote:
> > > > > > > On Mi, 2014-07-30 at 02:55 +0200, David Lamparter wrote:
> > > > > > > > GRE devices, for some reason, were coming up with an autoconfigured
> > > > > > > > address, but no ff00::/8 route in the local table.  This breaks any kind
> > > > > > > > of multicast, in particular OSPFv3, mDNS, - and ND.  In fact, IPv6 only
> > > > > > > > works at all because there is little need for ND on PtP devices.
> > > > > > > > 
> > > > > > > > Adding any other IPv6 address on the device would rectify this issue
> > > > > > > > through inet6_addr_add()/addrconf_add_dev() - and would leave the route
> > > > > > > > around even if the address was later removed.  (This is probably why
> > > > > > > > this issue was not discovered earlier.  AFAICS it has been there from
> > > > > > > > the beginning, e.g. aee80b5 "generate link local address for GRE
> > > > > > > > tunnel")
> > > > > > > 
> > > > > > > Yep, this is poor, but changing this will break user space...
> > > > > > 
> > > > > > How exactly will this break user space?
> > > > > 
> > > > > Because the multicast routes will always be restored after e.g. a route
> > > > > flush or manual route deletion. Scripts might depend on this.
> > > > 
> > > > Sorry, I still don't get it.  Without this patch you end up in an
> > > > inconsistent state, where a LL addr exists, but multicast doesn't work
> > > > (since ff00::/8 is missing from RT6_TABLE_LOCAL).
> > > 
> > > Sure, people can remove addresses and routes at will.
> > 
> > That's not the point.
> > 
> > user manually adds address on any if: ff00::/8 added.
> > kernel link-up autoconf addr on !gre: ff00::/8 added.
> > kernel link-up autoconf addr on gre:  no ff00::/8.
> 
> Ah sorry, I am ok with your patch that we generate a ff00::/8 multicast
> route if we set a gre interface up. Getting rid of the logic, that we
> try to add the ff00::/8 on every addition of an address to an interface
> would be a change which concerns because of backward compatibility
> reasons.

With IPv6LL address generation modes (IFLA_INET6_ADDR_GEN_MODE) the
kernel might not be handling the LL address, so I'd like to keep
addrconf_add_dev() in the inet6_addr_add() codepath.  Having the
multicast route is useful/correct no matter who adds the LL address to
the interface.

I think you alluded to this earlier, but I just wanted to bring it up.

Dan

> Especially this also creates multicast routes on sit-non-ptp/isatap
> routes, which actually don't need one.
> 
> > This is about automatic kernel behaviour in device up/change
> > notifications.  The user can always shoot himself in the foot.  This is
> > the kernel shooting the user in the foot in one particular and quite
> > specific instance and without a request to do so.
> 
> Agreed.
> 
> > > > Userspace is not supposed to touch RT6_TABLE_LOCAL in general, and, the
> > > > kernel will actually refuse installing the ff00::/8 route into the local
> > > > table from userspace (because there will be other ff00::/8 routes from
> > > > other interfaces, so you get "File exists").  You can delete the route
> > > > (and thus break mcast), but not add it.  The only way to add it is to
> > > > add an address.
> > > 
> > > People really do flush the routing table.
> > 
> > This is RT6_TABLE_LOCAL.  Most people aren't even aware it exists.  And
> > even though I can't find a reference for it, my memory tells me that
> > "table local" is supposed to be under the kernel's authority.
> 
> Yep, but still provide ip -6 route flush table all, which also clears
> the local table. And I guess people depend on ff00:: multicast routes
> being inserted as soon as they add addresses.
> 
> Bye,
> 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


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