netdev - Re: [RFC] ipv6: use a random ifid for headerless 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87bn9semf1.fsf@nemi.mork.no>
Date:	Mon, 14 Dec 2015 22:43:30 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	netdev@...r.kernel.org,
	吉藤英明 <hideaki.yoshifuji@...aclelinux.com>
Subject: Re: [RFC] ipv6: use a random ifid for headerless devices

Hannes Frederic Sowa <hannes@...essinduktion.org> writes:

> Sorry for answering so late...

No problem.  There is no rush here AFAICS.  Thanks for taking the time
to look at this.

> What do you think about simply using IN6_ADDR_GEN_MODE_RANDOM?

Yes, that's fine with me (actually what I first used :)

>> I guess we should check &net->ipv6.devconf_dflt->stable_secret too
>> before choosing the default mode.  IN6_ADDR_GEN_MODE_STABLE_PRIVACY is a
>> more approproate default if a default secret is set.  IMHO, this should
>> really be the case without the proposed change too, but it isn't. The
>> current behaviour confuses me: Setting 'default' changes all existing
>> interfaces, but does not change the default for new interfaces. Is that
>> right?
>
> Nope, that is a good point. I think we should do that unconditionally.
> If we have a stable secret set, which we can use, we always should use
> this address generation mode. Can you send the addition of this as a
> separate patch so we can propose it for stable? Otherwise I can do that,
> too.

I can do that if it can wait for whenever I get around to actually
submit this.  No guarantee that will be in time for v4.5.


>>> My proposal would be to use the stable privacy generator in case the
>>> device does not have a device address for EUI-48 generation with a
>>> secret which we simply generate on the stack. Let's factor out the part
>>> of the generator which depends on the inet6_dev and cnf bits for that.
>> 
>> Not sure I get this part either.  The point was to have stable addresses
>> for the lifetime of the netdev.  We can generate the secret on the
>> stack, but we will still need to stash it somewhere.  That could of
>> course be to a new field.  But I don't see the point since there is no
>> way you can combine this mode with IN6_ADDR_GEN_MODE_STABLE_PRIVACY.
>> Only one mode can be active at, and that mode can then own the secret.
>
> Ok, your argument makes sense.
>
>> As long as we can manage to introduce this without changing any existing
>> behaviour, of course.
>
> Besides the naming I think your patch looks fine.

Thanks!  Will fixup that and formally submit when I find some time.


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