netdev - Re: [patch iproute2 v2 0/2] add support for IFA_F

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: <1389022909.23397.4.camel@weing>
Date:	Mon, 06 Jan 2014 16:41:49 +0100
From:	Thomas Haller <thaller@...hat.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
	stephen@...workplumber.org, dcbw@...hat.com
Subject: Re: [patch iproute2 v2 0/2] add support for IFA_F_MANAGETEMPADDR

On Sat, 2014-01-04 at 12:35 +0100, Hannes Frederic Sowa wrote:
> On Sat, Jan 04, 2014 at 12:21:51PM +0100, Thomas Haller wrote:
> > > > >Also, I saw that NetworkManager switched to install autoconf addresses
> > > > >as /128, doesn't this break with IFA_F_MANAGETEMPADDR, as you expect a /64
> > > > >prefixlen?
> > > > 
> > > > /64 is required
> > > 
> > > Ok, currently NM seems to "violate" that as it installs autoconf addresses
> > > with 128 prefixlen, so IFA_F_MANAGETEMPADDR should not work on them.
> > > (currently observed on Fedora 20).
> > 
> > True, I noticed that too. I think that is a bug in NM to add the
> > addresses as /128. Probably, we will fix that soon.
> 
> The change could be valid. Otherwise currently NM could not correctly handle
> prefix information in RAs in some cases:
> 
> It is possible to let the client generate an autonomously address in a
> prefix which is actually not on-link (L=0). Kernel would automatically
> create prefix route by mistake, if NM tries to install such an address
> with /64 prefix. This does not happen if the prefix address uses 128
> prefixlen.
> 
> Would be great to have feedback on this, as this could be easily solved by an
> additional ifa_flag.
> 
> Greetings,
> 
>   Hannes
> 


Hi Hannes,


good point. I think, the user-space application (NetworkManager) should
add the autoconf addresses as /64. But the kernel should not generate
any routes in that case. It's up to the application to add them
(depending on the on-link flag).


What do you think about something like:



diff --git i/net/ipv6/addrconf.c w/net/ipv6/addrconf.c
index 6c16345..5a4c382 100644
--- i/net/ipv6/addrconf.c
+++ w/net/ipv6/addrconf.c
@@ -2433,8 +2433,11 @@ static int inet6_addr_add(struct net *net, int ifindex,
 			    valid_lft, prefered_lft);
 
 	if (!IS_ERR(ifp)) {
-		addrconf_prefix_route(&ifp->addr, ifp->prefix_len, dev,
-				      expires, flags);
+		if (ifa_flags & IFA_F_MANAGETEMPADDR == 0) {
+			addrconf_prefix_route(&ifp->addr, ifp->prefix_len, dev,
+					      expires, flags);
+		}
+
 		/*
 		 * Note that section 3.1 of RFC 4429 indicates
 		 * that the Optimistic flag should not be set for


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)