netdev - Re: [PATCH net-next] ip6_tunnel: ensure to always have a link local address

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: <8761uz6zra.fsf@nemi.mork.no>
Date:	Wed, 21 Aug 2013 13:37:29 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	nicolas.dichtel@...nd.com
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH net-next] ip6_tunnel: ensure to always have a link local address

Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:

> Le 21/08/2013 11:02, Bjørn Mork a écrit :
>> Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:
>>> Le 21/08/2013 08:48, David Miller a écrit :
>>>
>>>> Applied, but this brings up an issue I keep noticing.
>>>>
>>>> We talk about eth_random_addr() and "uniqueness" together all the
>>>> time, but the former never implies the latter.
>>>>
>>>> And we're going to run into situations where any conflicts generated
>>>> by this random address generater will cause reall failures.
>>>>
>>>> Therefore we'll have to create a system to prevent them.  Probably
>>>> using some simple table that keeps track of the addresses we've
>>>> generated.
>>>>
>>> Ok, I will look at this.
>>
>> Are eth_random_addr() collisions really any different than interfaces
>> having the same address for other reasons?
> I would tend to say yes, it's different.
> It's easy for an administrator to fix a configuration for a physical
> interface, because it's statically configured and there is a limited
> number of interfaces.
>
> For virtual interfaces, they can be dynamically created and destroyed
> by daemons and we can have a lot of interfaces. Hence it could be hard
> to fix them.

If they are created by daemons then it should be up to the daemons to
fix them.  Or?

> Trying to avoid these errors at kernel level could be useful.

I strongly believe in fixing configuration issues in userspace if at all
possible.  You are setting a new policy every time you implement an
automatic fix or workaround.  It is so much better to keep that out of
the kernel, or the next question you will face is "How do I change this
policy? I want the addresses to be assigned by function Y"

I see no reason why the daemon creating these interfaces can't also
fixup any collisions.  Or maybe better: If your daemon create millions
of interfaces, and cares about unique addresses, then it should
implement it's own address management.

> I've start to write a patch, and to test it I've just run a simple
> test which generate 1 000 000 of random addresses. I've run it several
> times (maybe not enough ;-)) and I never get a duplicated address...

Well, there are only 2^46 combinations so you are guaranteed to hit a
collision if you just generate 70 368 744 177 665 random addresses :-)


Bjørn
--
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